Re: breaking TLS (Was: Re: multiplexing -- don't do it)

On 04/03/2012 12:47 AM, William Chan (陈智昌) wrote:

>> You really mean "prevent" there? POSTing a rot13 version of the
>> corporate secret won't work? And I thought more anti-porn policies
>> were domain name and not content based.
>>
>
> I don't mean _completely_ prevent. But help stop the 9X% case? Yeah, I
> think that's what they're shooting for. I'm not well versed in the
> intricacies of IT policies using these SSL MITM proxies

Me neither. That's why I asked. But I'd like to know not
just about the policy they want to (or pay to) enforce,
but rather also about the effectiveness of their attempts
at enforcement.

S

 > (I suspect someone
> else on the mailing list is), but I know there are schools and what not
> which want to filter based on content, since schools want this from Google
> (see http://support.google.com/websearch/bin/answer.py?hl=en&answer=173733).
>
>
>> If there's published evidence of the effectiveness of that kind of
>> thing I've not seen it, but I didn't go looking. Saying its obvious
>> doesn't help me at least.
>>
>> I can more easily envisage spotting malware on the inbound side
>> as maybe effective but don't know how much of that is coming
>> via TLS.
>>
>> Really, I'm asking for evidence here, not just trying to score
>> points.
>>
>> S.
>>
>>
>>>> There is plenty of evidence that people sell this kind of thing and that
>>>> people use this kind of thing, but if its trivially defeated we're into
>>>> security theatre.
>>>>
>>>
>>>
>>> I'm not sure what you mean by "trivially defeated", but if you mean
>>> whether
>>> or not SSL is subverted by these MITM boxes, then it's obvious that this
>>> is
>>> already the case. See
>>> https://www.corelan.be/index.**php/2012/03/14/blackhat-eu-**2012-day-1/<https://www.corelan.be/index.php/2012/03/14/blackhat-eu-2012-day-1/>for
>>> example. The SSL MITM proxy did not do any certificate validation.
>>>
>>>
>>>   If that were the case, then maybe e2e security isn't worth giving
>>>> up for so little.
>>>>
>>>>
>>>>   I don't disagree with your concerns, of course.  This work needs a lot
>>>> of
>>>>
>>>>> scrutiny.  But I do think we can improve overall SSL adoption if we
>>>>> recognize what people are going to do without these types of features.
>>>>>
>>>>>
>>>> The problem is, scrutiny will not enable us to square a circle, which
>>>> may be what's involved here.
>>>>
>>>> S
>>>>
>>>>
>>>>
>>>>   Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Stephen.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>   I do understand that there are percieved-real requirements here for
>>>>>>>> enterprise middleboxes to snoop but we've not gotten IETF consensus
>>>>>>>> to
>>>>>>>> support that kind of feature in our protocols.
>>>>>>>>
>>>>>>>>
>>>>>>>>   sure we do. 2616 already contemplates and supports proxies - just
>>>>>>> not
>>>>>>> with https.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Stephen.
>>>>>>>> PS: I'm not angling for better http auth here. Even if we get that
>>>>>>>> there will be many passwords and other re-usable credentials in use
>>>>>>>> for pretty much ever and the argument against breaking TLS will
>>>>>>>> remain.
>>>>>>>>
>>>>>>>>
>>>>>>>>   Auth in fact may be the answer to the issue of trust for a server to
>>>>>>> place in a proxy (re the client cert issue).
>>>>>>>
>>>>>>> There may not be a good answer for client certs, and it may be the
>>>>>>> only
>>>>>>> way to support them is to continue to tunnel.
>>>>>>>
>>>>>>> At least they are not that prevalent so that in cases where they are
>>>>>>> required, tunneling can be allowed.
>>>>>>>
>>>>>>> Adrien
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   Mike
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   The proxy can still not see the facebook traffic in the clear so
>>>>>>>>> the
>>>>>>>>>
>>>>>>>>>> admin will still either need to block facebook entirely or do a
>>>>>>>>>> MITM.
>>>>>>>>>> Peter
>>>>>>>>>> On Mon, Apr 2, 2012 at 5:11 PM, Mike Belshe<mike@belshe.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Mon, Apr 2, 2012 at 2:08 PM, Adrien W. de
>>>>>>>>>>> Croy<adrien@qbik.com>wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   ------ Original Message ------ From: "Mike
>>>>>>>>>>>> Belshe"<mike@belshe.com>    To: "Adrien W. de Croy"<
>>>>>>>>>>>> adrien@qbik.com>
>>>>>>>>>>>> Cc: "Amos Jeffries"<squid3@treenet.co.nz******>;"
>>>>>>>>>>>> ietf-http-wg@w3.org
>>>>>>>>>>>>
>>>>>>>>>>>> "<
>>>>>>>>>>>>
>>>>>>>>>>>> ietf-http-wg@w3.org>    Sent: 3/04/2012 8:52:22 a.m. Subject: Re:
>>>>>>>>>>>> multiplexing -- don't do it
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Apr 2, 2012 at 1:43 PM, Adrien W. de Croy<
>>>>>>>>>>>> <adrien@qbik.com>    adrien@qbik.com>    wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>   ------ Original Message ------ From: "Mike
>>>>>>>>>>>>> Belshe"<mike@belshe.com>mike@******belshe.com<mike@belshe.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Apr 2, 2012 at 6:57 AM, Amos Jeffries<
>>>>>>>>>>>>> <squid3@treenet.co.nz><squid3@******treenet.co.nz<squid3@**
>>>>>>>>>>>>>
>>>>>>>>>>>>> treenet.co.nz<squid3@treenet.**co.nz<squid3@treenet.co.nz>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>    squid3@treenet.co.nz>    wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   On 1/04/2012 5:17 a.m., Adam Barth wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sat, Mar 31, 2012 at 4:54 AM, Mark Nottingham wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    On 31/03/2012, at 1:11 PM, Mike Belshe wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   For the record - nobody wants to avoid using port 80 for new
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   protocols. I'd love to! There is no religious reason that we
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> don't - its just that we know, for a fact, that we can't do
>>>>>>>>>>>>>>>>> it without subjecting a non-trivial number of users to
>>>>>>>>>>>>>>>>> hangs,
>>>>>>>>>>>>>>>>> data corruption, and other errors. You might think its ok
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> someone else's browser to throw reliability out the window,
>>>>>>>>>>>>>>>>> but nobody at Microsoft, Google, or Mozilla has been willing
>>>>>>>>>>>>>>>>> to do that…
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>   Mike -
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't disagree on any specific point (as I think you know),
>>>>>>>>>>>>>>>> but I would observe that the errors you're talking about can
>>>>>>>>>>>>>>>> themselves be viewed as transient. I.e., just because they
>>>>>>>>>>>>>>>> occur in experiments now, doesn't necessarily mean that they
>>>>>>>>>>>>>>>> won't be fixed in the infrastructure in the future --
>>>>>>>>>>>>>>>> especially if they generate a lot of support calls, because
>>>>>>>>>>>>>>>> they break a lot MORE things than they do now.
>>>>>>>>>>>>>>>> Yes, there will be a period of pain, but I just wanted to
>>>>>>>>>>>>>>>> highlight one of the potential differences between deploying
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> standard and a single-vendor effort. It's true that we can't
>>>>>>>>>>>>>>>> go too far here; if we specify a protocol that breaks
>>>>>>>>>>>>>>>> horribly
>>>>>>>>>>>>>>>> 50% of the time, it won't get traction. However, if we have a
>>>>>>>>>>>>>>>> good base population and perhaps a good fallback story, we
>>>>>>>>>>>>>>>> *can* change things.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   That's not our experience as browser vendors. If browsers
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> offer
>>>>>>>>>>>>>>> an HTTP/2.0 that has a bad user experience for 10% of users,
>>>>>>>>>>>>>>> then major sites (e.g., Twitter) won't adopt it. They don't
>>>>>>>>>>>>>>> want to punish their users any more than we do.
>>>>>>>>>>>>>>> Worse, if they do adopt the new protocol, users who have
>>>>>>>>>>>>>>> trouble will try another browser (e.g., one that doesn't
>>>>>>>>>>>>>>> support HTTP/2.0 such as IE 9), observe that it works, and
>>>>>>>>>>>>>>> blame the first browser for being buggy. The net result is
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> we lose a user and no pressure is exerted on the
>>>>>>>>>>>>>>> intermediaries
>>>>>>>>>>>>>>> who are causing the problem in the first place.
>>>>>>>>>>>>>>> These are powerful market force that can't really be ignored.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   So the takeway there is pay attention to the intermediary
>>>>>>>>>>>>>> people
>>>>>>>>>>>>>> when they say something cant be implemented (or won't scale
>>>>>>>>>>>>>> reasonably).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>   I agree we should pay attention to scalability - and we have.
>>>>>>>>>>>>> Please don't disregard that Google servers switched to SPDY with
>>>>>>>>>>>>> zero additional hardware (the google servers are fully
>>>>>>>>>>>>> conformant
>>>>>>>>>>>>> http/1.1 proxies with a lot more DoS logic than the average
>>>>>>>>>>>>> site). I know, some people think Google is some magical place
>>>>>>>>>>>>> where scalability defies physics and is not relevant, but this
>>>>>>>>>>>>> isn't true. Google is just like every other site, except much
>>>>>>>>>>>>> much bigger. If we had a 10% increase in server load with SPDY,
>>>>>>>>>>>>> Google never could have shipped it. Seriously, who would roll
>>>>>>>>>>>>> out
>>>>>>>>>>>>> thousands of new machines for an experimental protocol? Nobody.
>>>>>>>>>>>>> How would we have convinced the executive team "this will be
>>>>>>>>>>>>> faster", if they were faced with some huge cap-ex bill? Doesn't
>>>>>>>>>>>>> sound very convincing, does it? In my mind, we have already
>>>>>>>>>>>>> proven clearly that SPDY scales just fine.
>>>>>>>>>>>>> But I'm open to other data. So if you have a SPDY implementation
>>>>>>>>>>>>> and want to comment on the effects on your server, lets hear it!
>>>>>>>>>>>>> And I'm not saying SPDY is free. But, when you weigh costs (like
>>>>>>>>>>>>> compression and framing) against benefits (like 6x fewer
>>>>>>>>>>>>> connections), there is no problem. And could we make
>>>>>>>>>>>>> improvements
>>>>>>>>>>>>> still? Of course. But don't pretend that these are the critical
>>>>>>>>>>>>> parts of SPDY. These are the mice nuts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For a forward proxy, there are several main reasons to even
>>>>>>>>>>>>> exist:
>>>>>>>>>>>>> a) implement and enforce access control policy b) audit usage c)
>>>>>>>>>>>>> cache
>>>>>>>>>>>>> you block any of these by bypassing everything with TLS, you
>>>>>>>>>>>>> have
>>>>>>>>>>>>> a non-starter for corporate environments. Even if currently
>>>>>>>>>>>>> admins kinda turn a blind eye (because they have to) and allow
>>>>>>>>>>>>> port 443 through, as more and more traffic moves over to 443,
>>>>>>>>>>>>> more pressure will come down from management to control it.
>>>>>>>>>>>>> Best we don't get left with the only option being MITM.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   In my talk at the IETF, I proposed a solution to this.
>>>>>>>>>>>> Browsers need to implement SSL to trusted proxies, which can do
>>>>>>>>>>>> all of the a/b/c that you suggested above. This solution is
>>>>>>>>>>>> better
>>>>>>>>>>>> because the proxy becomes explicit rather than implicit. This
>>>>>>>>>>>> means that the user knows of it, and it IT guys knows of it. If
>>>>>>>>>>>> there are problems, it can be configured out of the system.
>>>>>>>>>>>> Implicit proxies are only known the the IT guy (maybe), and can't
>>>>>>>>>>>> be configured out from a client. The browser can be made to honor
>>>>>>>>>>>> HSTS so that end-to-end encryption is always enforced
>>>>>>>>>>>> appropriately.
>>>>>>>>>>>> Further, proxies today already need this solution, even without
>>>>>>>>>>>> SPDY. Traffic is moving to SSL already, albeit slowly, and
>>>>>>>>>>>> corporate firewalls can't see it today. Corporate firewall admins
>>>>>>>>>>>> are forced to do things like block facebook entirely to prevent
>>>>>>>>>>>> data leakage. But, with this solution, they could allow facebook
>>>>>>>>>>>> access and still protect their IP. (Or they could block it if
>>>>>>>>>>>> they
>>>>>>>>>>>> wanted to, of course).
>>>>>>>>>>>> Anyway, I do agree with you that we need better solutions so that
>>>>>>>>>>>> we don't incur more SSL MITM. Many corporations are already
>>>>>>>>>>>> looking for expensive SSL MITM solutions (very complex to rollout
>>>>>>>>>>>> due to key management) because of the reasons I mention above,
>>>>>>>>>>>> and
>>>>>>>>>>>> its a technically inferior solution.
>>>>>>>>>>>> So lets do it!
>>>>>>>>>>>>
>>>>>>>>>>>> I basically agree with all the above, however there is the ISP
>>>>>>>>>>>> intercepting proxy to think about.
>>>>>>>>>>>> Many ISPs here in NZ have them, it's just a fact of life when
>>>>>>>>>>>> you're 150ms from the US and restricted bandwidth. Pretty much
>>>>>>>>>>>> all
>>>>>>>>>>>> the big ISPs have intercepting caching proxies.
>>>>>>>>>>>> There's just no way to make these work... period...
>>>>>>>>>>>> unless the ISP is to
>>>>>>>>>>>> a) try and support all their customers to use an explicit proxy,
>>>>>>>>>>>> or b) get all their customers to install a root cert so they can
>>>>>>>>>>>> do MITM.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>   Maybe we need a better way to force a client to use a proxy, and
>>>>>>>>>>>
>>>>>>>>>>>   take the pain out of it for administration. And do it securely
>>>>>>>>>>>> (just remembering why 305 was deprecated).
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>   Do proxy pacs or dhcp work for this?
>>>>>>>>>>> Note that we also need the browsers to honor HSTS end-to-end, even
>>>>>>>>>>> if we turn on "GET https://". Mike
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   Adrien
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Mike
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>   Adrien
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Mike
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   With plenty of bias, I agree.
>>>>>>>>>>>>>
>>>>>>>>>>>>>   AYJ
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>

Received on Monday, 2 April 2012 23:54:47 UTC