W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

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

From: Adrien W. de Croy <adrien@qbik.com>
Date: Wed, 18 Jul 2012 03:25:11 +0000
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <em7dabfa75-0cf3-48ce-ba8d-30e3057d5485@bombed>

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.


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.

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.  

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.

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


COST

Google, Facebook and Twitter don't need to spend much on SSL certs from 
CAs.  Not in the scheme of things.

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


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.

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?  

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.

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


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.


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.

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.

[**] 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.
Received on Wednesday, 18 July 2012 03:25:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 18 July 2012 03:25:41 GMT