Re: [TLS] TLS and middleboxes again

Juho Vähä-Herttua <juhovh@iki.fi> Fri, 26 August 2011 10:52 UTC

Return-Path: <juhovh@iki.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A25021F8B4C for <tls@ietfa.amsl.com>; Fri, 26 Aug 2011 03:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkCavpLUpLz9 for <tls@ietfa.amsl.com>; Fri, 26 Aug 2011 03:52:32 -0700 (PDT)
Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1E321F8B50 for <tls@ietf.org>; Fri, 26 Aug 2011 03:52:32 -0700 (PDT)
Received: from mail.visino.fi (88.192.37.90) by jenni1.inet.fi (8.5.133) id 4DF73B28035C768F for tls@ietf.org; Fri, 26 Aug 2011 13:53:44 +0300
Received: from [130.233.194.212] (tko-add-212.cs.hut.fi [130.233.194.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 675D01FE9D for <tls@ietf.org>; Fri, 26 Aug 2011 13:53:44 +0300 (EEST)
Message-ID: <4E577B25.3040302@iki.fi>
Date: Fri, 26 Aug 2011 13:53:25 +0300
From: Juho Vähä-Herttua <juhovh@iki.fi>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: tls@ietf.org
References: <mailman.83.1314298812.6863.tls@ietf.org> <4E5764A6.8080701@gmail.com>
In-Reply-To: <4E5764A6.8080701@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] TLS and middleboxes again
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Aug 2011 10:52:33 -0000

26.8.2011 12:17, Yaron Sheffer kirjoitti:
> 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.

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 
> (re-handshake) this would not work because of the ongoing sequence 
> number that's MACed with each record.

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.

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

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


>
> Thanks,
>     Yaron
>
>
> On 08/25/2011 10:00 PM, tls-request@ietf.org wrote:
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 25 Aug 2011 10:39:57 +0300
>> From: Yoav Nir<ynir@checkpoint.com>
>> To:"tls@ietf.org List" <tls@ietf.org>
>> Subject: [TLS] TLS and middleboxes again
>> Message-ID:<036F4DE5-2E91-4946-87E2-F3258038E511@checkpoint.com>
>> 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:"internet-drafts@ietf.org" <internet-drafts@ietf.org>
>>> Date: August 25, 2011 10:30:46 AM GMT+03:00
>>> To:"i-d-announce@ietf.org" <i-d-announce@ietf.org>
>>> Subject: I-D Action: draft-nir-tls-keyshare-00.txt
>>> Reply-To:"internet-drafts@ietf.org" <internet-drafts@ietf.org>
>>>
>>> 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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>> End of TLS Digest, Vol 85, Issue 18
>> ***********************************
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls