Security and TOFU

[vineet garg]

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

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).

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.

@albert what do you say?

Regards
Vineet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20161115/2ce7a5f1/attachment.html>