<p dir="ltr"></p>
<p dir="ltr">On Nov 15, 2016 2:01 PM, "Giedrius" <<a href="mailto:iksius@gmail.com">iksius@gmail.com</a>> wrote:<br>
><br>
> On Mon, Nov 14, 2016 at 6:41 PM, Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>> wrote:<br>
> > On Mon, Nov 14, 2016 at 4:07 PM, Giedrius <<a href="mailto:iksius@gmail.com">iksius@gmail.com</a>> wrote:<br>
> >> What I am thinking about is not security of SSL or encryption<br>
> >> algorithms but rather trust-on-first-use method. As I understand this<br>
> >> method mostly relies on users ability to check and validate<br>
> >> certificate fingerprints. It might be ok for SSH where users can be<br>
> >> expected to be IT and security savvy, but in my opinion it is not ok<br>
> >> for a regular user. First of all certificate validation is not<br>
> >> enforced in any way, so the average user most often would just ignore<br>
> >> this step. Also, certificate fingerprints are quite complicated and<br>
> >> can make validation error prone or may discourage the validation step<br>
> >> altogether  (I am not sure how feasable it is, but an attacker could<br>
> >> try to generate its own certificates which would produce similar<br>
> >> fingerprints). Are such my wories invalid?<br>
> >><br>
> >> As I said, I am not security expert and I would be very glad if<br>
> >> someone corrected me :)<br>
> >><br>
> >> Giedrius<br>
> >><br>
> >>> Nothing in this life is completely fail- or hack-proof, but I think KDE<br>
> >>> Connect security is, at this point, pretty decent :)<br>
> >>><br>
> >>> Since the recent version 1.0, it uses SSL and trust-on-first-use, like SSH<br>
> >>> (which you could say is not hack-proof either, nothing is). Of course, SSH<br>
> >>> has likely been audited way more than kdeconnect, so if you are a security<br>
> >>> specialist and want to check kdeconnect for implementation errors or other<br>
> >>> security flaws, it would be of great help!<br>
> >>><br>
> >>> Albert<br>
> >>><br>
> >>> On Sun, Nov 13, 2016 at 6:50 PM, ixius ixius <<a href="mailto:iksius@gmail.com">iksius@gmail.com</a>> wrote:<br>
> >>><br>
> >>> > Hello,<br>
> >>> ><br>
> >>> > I am concerned about security aspect of the kde-connect pairing procedure.<br>
> >>> > I am no expert in security but as I understand the pairing of the devices<br>
> >>> > currently is not completely fail-(or hack-)proof. Am I right or am I<br>
> >>> > missing something? And if I am not wrong, I wonder if there are any plans<br>
> >>> > to solve the issues?<br>
> >>> ><br>
> ><br>
> >> As I understand this<br>
> > method mostly relies on users ability to check and validate<br>
> > certificate fingerprints<br>
> ><br>
> > How did you get to this conclusion?<br>
> ><br>
> > If the certificates aren't properly paired, it won't be possible to<br>
> > communicate both devices.<br>
> ><br>
> > Aleix<br>
><br>
> I am not talking about intercepting communications when devices are<br>
> already paired, but rather about pairing itself. One scenario I am<br>
> thinking about could be like this:<br>
><br>
> 1. There are two paired devices in the network with names (deviceName)<br>
> let say A and B<br>
> 2. There is a malicious actor connected to the same network who can<br>
> see device names as they are announced publicly<br>
> 3. This malicious actor can make a connection to device A using its<br>
> own unique deviceId, its own self-signed certificate but with<br>
> deviceName of the other device - B</p>
<p dir="ltr">Since A and B are already paired, it means A already has B's certificate, certificate from malicious user will not match and will lead to connection failure. Certificates are not compared only by name but public key and signatures are compared too. So malicious user will not even connect with B's identity. So A won't even receive pairing request. If malicious user tries to resend B's captured certificate, it does not have the private key needed for SSL procedure so connection would fail again.</p>
<p dir="ltr">That's is why it is called "trust on first use", once you trust a device it will be always secure for future transactions. Though the first use is vulnerable and susceptible to attacks. That's why in case of doubt you can always confirm fingerprint.</p>
<p dir="ltr">> 4. When connected, the malicious actor could request pairing on that device<br>
> 5. A user on device A would see a message that a device with name B<br>
> wants pairing<br>
> 6. At this place a smarter user would simply decline pairing as he<br>
> would understand that something fishy is happening. However if user is<br>
> not so smart, or maybe distracted or in a rush, he could think that<br>
> this is some glitch in software (maybe previous pairing got somehow<br>
> broken or something like that) and would accept the pairing request.<br>
> 7. If the pairing is accepted, a malicious actor becomes trusted and<br>
> could access sensitive information like clipboard content. The user<br>
> might now see two paired devices with same name and may choose to<br>
> unpair them, but at this point it might be already too late</p>
<p dir="ltr">Again since malicious user cannot connect with B's identity, all above points seems invalid.</p>
<p dir="ltr">Regards<br>
Vineet</p>