Re: HTTP2 Expression of Interest

On 19.07.2012 02:03, Yoav Nir wrote:
> Wow. It's like I have to run to the other side of the table to argue
> for the other side…
>
> On Jul 18, 2012, at 4:24 PM, Nicolas Mailhot wrote:
>>
>> That being said:
>>
>> 1. I don't read the bank (or other correspondence) of my users
>>
>> 2. I'm not asked to read the bank (or other correspondence) of my 
>> users,
>> either by management or a police state (divulging it would take a 
>> legal
>> injunction I think, never had to deal with those)
>
> It's a good thing that you don't read bank transactions and that you
> don't get asked to. But you could read the bank transactions if you
> wanted to (or were asked to). If the data goes over HTTP you can do 
> it
> with something as simple as TCPDUMP. If it goes over SSL, you'll need
> a TLS proxy.  The security issue is not that you want to do it, but
> that you and others with similar jobs to yours can do it.
>
>> 3. When confidential (company or user) data leaks it's always at the
>> server endpoints, usually because those endpoints didn't care a bit 
>> about
>> user data confidentiality.
>
> Well, we know that some countries monitor traffic for censorship and
> to discover dissidents. Most would call this data leakage, and it's
> not at the endpoints.
>
>> 12. we absolutely do *not* want to eavesdrop on bank accesses,
>> e-government forms, etc. We'd much prefer if such a traffic could be 
>> send
>> in encrypted payloads with in-clear routing metadata (there I differ 
>> a bit
>> from Willy, but I accept he has customers with stricter requirements 
>> than
>> ours)
>
> Does "we" include the no such agency?  Does it include its
> counterparts in Iran and Syria? There are all sorts of people
> installing middleboxes.

Quite right. There are. Please stop grouping all of them into the 
"spies" category. We aren't.

There *is* information REQUIRED to be in the clear for regular 
networking delivery. One would not encrypt the src/dst IP addresses in 
TCP and expect routers to deliver the packet successfully. So why insist 
on doing it for the whole HTTP connection pipeline?
  Encrypting the entity (or even just user-specific header data) is 
sufficient.


I've been quietly reading for the last day all these posts pretty much 
advocating TLS as the be-all and end-all of security. Quietly because I 
can't figure out whether to rant or ROFL for several hours.

So Rant it is...

TLS is *broken*, has been for just over two years now. MITM is 
happening. It is routinely done by the spy camp, down to and including 
home-users spying on their childrens Facebook habits.

Today we can for the most part identify who they are by the self-signed 
certificates inserted into the stream in unexpected places.

Mandating TLS across the board will only force the law-abiding and 
conscientious White-hat admins like Nicolas and many, MANY others to 
become MITM decryptors. Security is *guaranteed* to be lower when that 
happens. We will no longer be able to identify the White-hats doing what 
they are forced to, and the Black-hats vacuuming up private information.

If this goes much further we may not even be able to tell encrypted and 
non-encrypted data streams apart anymore.

/rant


We already have TLS in the form of port 443. It would be a trivial 
protocol matter to mandating HTTP/2 only be sent over that port.

However, we need something *better* than simple TLS wrappers to meet 
the current and future security needs in HTTP/2 on port 80. Which is 
where I believe the WG effort needs to design for.

AYJ

Received on Thursday, 19 July 2012 02:21:48 UTC