<div dir="ltr">Bluetooth has the same problem, and even though it uses a simpler "hash" to compare before pairing (a 6-digit number, IIRC), probably most users will ignore it anyway. I don't think we can do much to help in this case. Any ideas?</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 15, 2016 at 10:12 AM, vineet garg <span dir="ltr"><<a href="mailto:grgvineet@gmail.com" target="_blank">grgvineet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><p dir="ltr">On Nov 15, 2016 2:26 PM, "Giedrius" <<a href="mailto:iksius@gmail.com" target="_blank">iksius@gmail.com</a>> wrote:<br>
><br>
> On Tue, Nov 15, 2016 at 10:46 AM, vineet garg <<a href="mailto:grgvineet@gmail.com" target="_blank">grgvineet@gmail.com</a>> wrote:<br>
> > On Nov 15, 2016 2:01 PM, "Giedrius" <<a href="mailto:iksius@gmail.com" target="_blank">iksius@gmail.com</a>> wrote:<br>
> >><br>
> >> On Mon, Nov 14, 2016 at 6:41 PM, Aleix Pol <<a href="mailto:aleixpol@kde.org" target="_blank">aleixpol@kde.org</a>> wrote:<br>
> >> > On Mon, Nov 14, 2016 at 4:07 PM, Giedrius <<a href="mailto:iksius@gmail.com" target="_blank">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<br>
> >> >>> 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<br>
> >> >>> SSH<br>
> >> >>> (which you could say is not hack-proof either, nothing is). Of course,<br>
> >> >>> SSH<br>
> >> >>> has likely been audited way more than kdeconnect, so if you are a<br>
> >> >>> security<br>
> >> >>> specialist and want to check kdeconnect for implementation errors or<br>
> >> >>> 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" target="_blank">iksius@gmail.com</a>> wrote:<br>
> >> >>><br>
> >> >>> > Hello,<br>
> >> >>> ><br>
> >> >>> > I am concerned about security aspect of the kde-connect pairing<br>
> >> >>> > procedure.<br>
> >> >>> > I am no expert in security but as I understand the pairing of the<br>
> >> >>> > 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<br>
> >> >>> > 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<br>
> ><br>
> > Since A and B are already paired, it means A already has B's certificate,<br>
> > certificate from malicious user will not match and will lead to connection<br>
> > failure. Certificates are not compared only by name but public key and<br>
> > signatures are compared too. So malicious user will not even connect with<br>
> > B's identity. So A won't even receive pairing request. If malicious user<br>
> > tries to resend B's captured certificate, it does not have the private key<br>
> > needed for SSL procedure so connection would fail again.<br>
> ><br>
> > That's is why it is called "trust on first use", once you trust a device it<br>
> > will be always secure for future transactions. Though the first use is<br>
> > vulnerable and susceptible to attacks. That's why in case of doubt you can<br>
> > always confirm fingerprint.<br>
> ><br>
> >> 4. When connected, the malicious actor could request pairing on that<br>
> >> 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<br>
> ><br>
> > Again since malicious user cannot connect with B's identity, all above<br>
> > points seems invalid.<br>
> ><br>
> > Regards<br>
> > Vineet<br>
><br>
> I think you misunderstood me. To make the situation simpler, instead<br>
> of "malicious actor" let say there is another standard kde-connect<br>
> device C. On that device C I can change its name to B and request<br>
> pairing on device A. The user on device A would see name B and would<br>
> think that this request came from device B while actually it is from<br>
> C. If he accepted the pairing request, he would be trusting device C<br>
> he didn't actually inteded to trust</p>
</div></div><p dir="ltr">Yeah that's what trust on first use is, you have to carefully trust on first use, compare keys and signatures on both devices etc.. After that it is completely secure(integrity, authenticity, confidentiality and non repudiation is maintained).</p>
<p dir="ltr">I agree on that point that a normal user might ignore this step or make some error. There should be some enforced user friendly hash comparison method.</p>
<p dir="ltr">@albert what do you say?</p>
<p dir="ltr">Regards<span class="HOEnZb"><font color="#888888"><br>
Vineet</font></span></p>
</blockquote></div><br></div>