Subject: Re: [TLS] TLS and middleboxes again

From: Yaron Sheffer <[email-masked]>
Date: Fri, 26 Aug 2011 12:17:26 +0300

Hi,

I support this proposal. I think it is a lot more generic than the 
previous one, since it also supports mutual authentication (TLS-SRP) and 
client certs.

A few comments:
- On top of the encryption keys, we probably need to support sending the 
MAC keys. Subject to client and server policy of course.
- I think the idea of pushing records into the stream only works for the 
initial handshake, before the Change Cipher Spec message. Later on 
(re-handshake) this would not work because of the ongoing sequence 
number that's MACed with each record.
- IMHO the following sentence is miguided, and opens a major security 
loophole: "If a KeyShareInfo record is received with an unknown 
certificate, [...] the user MAY be prompted to authorize the decryption, 
and optionally change the configuration to allow future decryption by 
this certificate." Users will always say Yes when otherwise their 
communication will be interrupted. In other words, the proxy 
certificates must only be provisioned off-line, in advance, when the 
user can still make reasoned decisions. [As an example of this user 
behavior, I just approved myself the IETF's own expired certificate...]

Thanks,
     Yaron

On 08/25/2011 10:00 PM, [email-masked] wrote:
> ------------------------------
>
> Message: 2
> Date: Thu, 25 Aug 2011 10:39:57 +0300
> From: Yoav Nir<[email-masked]>
> To:"[email-masked] List"  <[email-masked]>
> Subject: [TLS] TLS and middleboxes again
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi all
>
> Several weeks ago, Dave McGrew submitted a draft for improving the workings of TLS proxies. As expected, this generated a lot of controversy, with some people saying that they'd rather hand over the session keys to the middlebox than to standardize a MitM attack.
>
> I was on the other side of that debate, but one problem with comparing the two alternatives is that for proxies there are several commercial products and Dave's draft, while there's nothing for key sharing. To remedy that, and help the discussion along, I've submitted the below draft. Comments and additional controversy are very welcome.
>
> Yoav
>
> Begin forwarded message:
>
>> From:"[email-masked]"  <[email-masked]>
>> Date: August 25, 2011 10:30:46 AM GMT+03:00
>> To:"[email-masked]"  <[email-masked]>
>> Subject: I-D Action: draft-nir-tls-keyshare-00.txt
>> Reply-To:"[email-masked]"  <[email-masked]>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>> 	Title           : A Method for Sharing Record Protocol Keys with a Middlebox in TLS
>> 	Author(s)       : Yoav Nir
>> 	Filename        : draft-nir-tls-keyshare-00.txt
>> 	Pages           : 11
>> 	Date            : 2011-08-25
>>
>>    This document contains a straw man proposal for a method for sharing
>>    symmetric session keys between a TLS client and a middlebox, so that
>>    the middlebox can decrypt the TLS-protected traffic.
>>
>>    This method is an alternative to the middlebox becoming a proxy.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nir-tls-keyshare-00.txt
> ------------------------------
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>
> End of TLS Digest, Vol 85, Issue 18
> ***********************************

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Fri, 26 Aug 2011 13:53:25 +0300

26.8.2011 12:17, Yaron Sheffer kirjoitti:
> previous one, since it also supports mutual authentication (TLS-SRP) 
> and client certs.

I support it as well, it sounds very similar to what I was working on a 
while back. I needed to sniff SSL traffic with Wireshark for debugging 
purposes, but the problem was that I could only sniff the connections 
that were doing an RSA key exchange with my own certificate, so that I 
could give the private key to Wireshark. Connections where I used my 
client to connect to a third party server or connections using DHE 
wouldn't work at all.

How I solved this was to use the weakness in TLS 1.0 and TLS 1.1 which 
allows to inject TLS records with an unknown type into the stream 
without breaking the connection, to prevent TLS 1.2 from being used I 
could simply disable it from my client. I then used that record to pass 
the decryption keys to Wireshark and got the connections in plain text 
without any modifications to the actual software, just had to replace 
the libssl or such in the client side.

I think it's a good idea to standardize a way for key sharing, there's a 
lot of reasons to allow decryption of the traffic for one party in the 
middle if the user gives consent. It shouldn't be too easy to enable 
though and users of it should be well aware of what they are doing.

> A few comments:
> - On top of the encryption keys, we probably need to support sending 
> the MAC keys. Subject to client and server policy of course.

I have no reason to support sending the MAC keys, and letting the proxy 
to modify the actual contents of the connection sounds a bit scary to 
me... What's the actual use case for this? I'm sure there's some, but I 
can't think of anything sensible right now. Basically sharing the MAC 
keys would make it similar with the certificate MitM attack currently used.

> - I think the idea of pushing records into the stream only works for 
> the initial handshake, before the Change Cipher Spec message. Later on 

That's a very good point, I don't think injecting records works after 
the initial handshake either. Then again on subsequent handshakes the 
certificate and signature info doesn't need to be sent, only the actual 
KeyShareInfo(keys) record is relevant. Current specification says that 
record is removed by middlebox, but if it were NOT removed, it would 
work without problems on re-handshakes as well. If the 
KeyShareInfo(keys) is properly RSA encrypted with the middlebox private 
key, it shouldn't impose any real threat to the connection as long as 
the middlebox private key is considered safe.

> certificate, [...] the user MAY be prompted to authorize the 
> decryption, and optionally change the configuration to allow future 
> decryption by this certificate." Users will always say Yes when 
> otherwise their communication will be interrupted. In other words, the 
> proxy certificates must only be provisioned off-line, in advance, when 
> the user can still make reasoned decisions. [As an example of this 
> user behavior, I just approved myself the IETF's own expired 
> certificate...]

I'm not sure if KeyShareInfo with an unknown certificate should ever be 
allowed... Configuring it as authorized might be even worse idea. Thank 
you for the draft anyway, I think if implemented widely it would be a 
better option than the proxy certificate currently used, because it's 
much better to be able to only share the decryption keys without the MAC 
keys.

Juho

>> Several weeks ago, Dave McGrew submitted a draft for improving the 
>> workings of TLS proxies. As expected, this generated a lot of 
>> controversy, with some people saying that they'd rather hand over the 
>> session keys to the middlebox than to standardize a MitM attack.
>>
>> I was on the other side of that debate, but one problem with 
>> comparing the two alternatives is that for proxies there are several 
>> commercial products and Dave's draft, while there's nothing for key 
>> sharing. To remedy that, and help the discussion along, I've 
>> submitted the below draft. Comments and additional controversy are 
>> very welcome.
>>
>> Yoav
>>
>> Begin forwarded message:
>>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 26 Aug 2011 17:37:51 +0200

> keys would make it similar with the certificate MitM attack currently used.

Or maybe a different MAC key is provided to the middle box, which will
use this to rewrite a MAC message (and tag it with a different
content-type such as modified-record).

That way the client will know whether the packet received is original
or modified.

regards,
Nikos

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Fri, 26 Aug 2011 12:11:44 -0400

There COULD be justifiable need to observe the traffic and thus to share the encryption key. At this time I see _no_ justifiable need to modify the traffic and thus believe that the MAC key must not be shared with the third parties. 

If there's something wrong with the content - force the connection to close/abort.
 
--
Regards,
Uri

----- Original Message -----
From: Nikos Mavrogiannopoulos [mailto:[email-masked]]
Sent: Friday, August 26, 2011 11:37 AM
To: Juho Vähä-Herttua <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [TLS] TLS and middleboxes again

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Fri, 26 Aug 2011 23:20:51 +0300

On Aug 26, 2011, at 1:53 PM, Juho Vähä-Herttua wrote:

> I support it as well,

This is meant as a straw man proposal. I still think that an actual proxy is better.

> me... What's the actual use case for this?

An attacker sends your gmail (or hotmail, of iCloud) account a document containing malicious macros. You click the document link within the website to download it. The middlebox detects the malware. Without MAC keys, it can only break the connection, which looks weird - like the download has failed. With MAC keys, it can redirect to a page that says "The file you tried to download contains the XXXXX virus", or it can even let you download a document that says that.

> much better to be able to only share the decryption keys without the MAC 

I agree that configuration is a difficult issue, but I don't see how we can take the user out of the loop. I don't want to allow Starbucks to decrypt my TLS traffic, but I will probably accept this from my employer. These days we have a lot of unmanaged hardware at companies (a lot of Macs, and almost all cell-phones) and even more unmanaged browsers.