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

On Tue, Jul 17, 2012 at 8:25 PM, Adrien W. de Croy <adrien@qbik.com> wrote:

>
> Mandating use of (c.f. support for) crypto in HTTP will prevent it from
> being deployable in a significant number of scenarios, thereby requiring
> ongoing use of HTTP/1.1.
>
>

This is true for any manifestation of HTTP/2.0 with or without security.



>
> DESIRABILITY OF PRIVACY
>
>   Proponents of mandatory crypto
> are making an assumption that privacy is ALWAYS desirable.
>
> It is not ALWAYS desirable.
>
> In many cases privacy is undesirable or even illegal.
>
> 1. Many states have outlawed use of crypto.  So will this be HTTP only for
> the "free" societies?  Or is the IETF trying to achieve political change in
> "repressed" countries?  I've dealt with our equivalent of the NSA on this
> matter.  Have you?  I know the IETF has a neutral position on enabling
> wiretapping.  Mandating SSL is not a neutral / apolitical stance.  Steering
> HTTP into a collision course with governments just doesn't seem like much
> of a smart idea.
>

I don't know of states that prohibit TLS.  Do they exist?  Which ones are
they?  Can you list them?

Are you saying that HTTP/2.0 must be compliant with the laws of every
country?  And that any country passing a law making HTTP/2.0 features
illegal will block HTTP/2.0? :-)

Sites that are truly concerned can still negotiate the null cypher, I
suppose.


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


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