Security and TOFU

[Giedrius]

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