Re: Some reasons why mandating use ofSSL for HTTP is a really bad idea

On Tue, Jul 17, 2012 at 9:09 PM, Mike Belshe <mike@belshe.com> wrote:

>
> [snip]
>
>> 2. Most prisons do not allow inmates to have privacy when it comes to
>> communications.  Would you deny [*] all prisoners access to the web?  There
>> are other scenarios where privacy is not expected, permitted or desirable.
>>
>
> I doubt this is a problem.  If it is, then the poor prisoners are already
> being denied access to their banks, most all of which require TLS.
>
>

FWIW, the California Department of Corrections restricts prisoners from
using the network connected computers at any time, let alone access the
Internet. I believe similar policies are in effect in most states across
the country. Of course... I can only speak for regulations within the U.S.

Still no where near convinced that mandatory TLS is even remotely
worthwhile. There are simply too many perfectly valid cases where it's
completely unnecessary and downright silly to assume it's needed.

There is no evidence, that I have seen, that demonstrates that Mandatory
TLS would make HTTP/2.0 any more secure than optional TLS.

- James


>
>> 3. Many situations require communications to be open and visible.  Would
>> you rather your network infrastructure phoned home with SSL or HTTP that
>> you can see.
>>
>
> Can you enumerate these?  For debugging, of course it makes sense for
> endpoints to have unencrypted modes.  We can also build better tools, such
> as the improvements for decoding TLS traffic with Wireshark that have
> landed recently.
>
>
>>
>> 4. Scanning for malware at a gateway.  This requirement is NOT going
>> away, and the SSL will be brute-forced / spoofed etc to achieve this.
>> Mandating SSL will just make it easier for malware to propagate, since you
>> make it harder to scan [**].
>>
>
> This problem exists today; IP leakage has to be checked even across TLS
> based connections.  Solutions for these corporate IT groups exist,
> including TLS aware proxies and TLS man in the middle.  Several vendors
> provide these solutions today.
>
>
>>
>>
>> COST
>>
>> Google, Facebook and Twitter don't need to spend much on SSL certs from
>> CAs.  Not in the scheme of things.
>>
>
> Actually, this is not true.  These companies spend the most on "well
> rooted" certificates.
>
>
>
>>
>> What about the other hundreds of millions of us running web servers.  You
>> gonna buy us our certs?  I better buy me some shares in Verisign et al..
>>
>
> They are free - https://www.startssl.com/
>
>
>>
>>
>> SECURITY
>>
>> Mandating SSL on all devices with HTTP stacks (e.g. your home network
>> infrastructure, NAS, Modem etc) cannot be practically done while we rely on
>> CAs to issue certs, and while those certs must be installed, expired,
>> updated etc etc.
>>
>
> I think it can!
>
>
>>
>> Or do you think manufacturers of such hardware should just ship with some
>> default cert?  Self-signed maybe?  And while you're at it, why not get
>> every machine in the world to trust that cert...  Oh dear, do we have a
>> security problem?
>>
>
> I think we could do self signed certs and also continue to improve the CA
> infrastructure.  I'd like to see Google become a CA with a super-easy
> certificate issuing process.
>
>
>>
>> Frankly I think mandating SSL for all HTTP/2.0 will just break SSL for
>> the world (or more likely consign HTTP/2.0 to relative obscurity).
>>
>
>> It's been alluded to that we'd replace the CA infrastructure.  Don't you
>> think it's premature to propose mandatory use of SSL when you haven't
>> proposed what would replace the CA infrastructure yet?  That's like
>> starting building a spaceship for Alpha Centauri based on a rocket engine
>> that hasn't been invented yet.
>>
>
> Many researchers and security experts agree we need a CA overhaul.  But
> this doesn't mean that the existing CA infrastructure is not usable.
>  Despite its flaws, it is better than no CA system.  And we can fix it!
>  Look at this as an opportunity, not a hurdle.
>
>
>>
>> You'd have to replace CRL and OCSP checking protocols, because they use
>> HTTP, and mandating use of SSL for that would create a paradox (how do you
>> check the cert on the connection used to check the cert ad infinitum).
>>
>
> Naw, the browsers wouldn't need to validate the cert from the OCSP server
> because the contents that they fetch are self-signed and verifiable
> independently.
>
>
>>
>>
>> OTHER
>>
>> Most people here seem to focus on issues such as CPU load, extra R-Ts
>> introduced by the SSL setup etc.  Those are valid concerns, but they are
>> easier to overcome than the others. They aren't easy to overcome, just
>> easier.
>>
>
> Agree.
>
>
>>
>>
>> Seems to me it would be a whole lot simpler and more compatible with the
>> actual world we actually live on just to make crypto optional.
>>
>
> True.  It would also be a whole lot less secure, leave users exposed on
> the net to trust that every single website remembered to secure the
> communicates of private data and that none of them use sniffable
> cookies....
>
>
>
>>
>> Adrien
>>
>>
>> [*] We can't realistically expect server operators to indefinitely
>> support both HTTP/2.0 and HTTP/1.1.  Some will inevitably drop HTTP/1.1
>> support, and that part of the internet will then become unavailable to
>> those forced to keep using HTTP/1.1, effectively denying those users.
>>
>
> Actually, HTTP/1.1 will become like IE6.  It will be this legacy thing
> holding back the world.  Eventually there will be big pushes to rid the
> world of this insecure protocol that we wish we no longer had lying around
> :-)
>
>
>>
>>  [**] T
>> here has been some discussion about enabling intermediaries to be able to
>> see plaintext payload by terminating the SSL connection at each end.  This
>> hasn't progressed enough, and the current proposals still basically bypass
>> intermediaries AFAICT.
>>
>>
>
> Agree it needs more work.  But I don't think this should be a condition of
> making HTTP/2.0 a more secure protocol.
>
> Mike
>
>
>