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

------ Original Message ------
From: "Mike Belshe" mike@belshe.com
>
>
>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.

I don't know if it should be a goal though.  IMO the goal should be to 
replace the old with something better, not replace it with something 
that can only be used by a subset of current users, and therefore 
requires continued perpetual use of the old.



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

It's hard to get recent information, but my understanding is that a lot 
of of people live in jurisdictions where crypto is tightly controlled.

E.g. China, India, several mid-eastern and former soviet countries.
>
>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? :-)

In practice, we would have different levels of difficulty ignoring laws 
of a country depending on which country that was.

If the US passed a law that banned it, and threatened to put you in 
jail, you may give that more weight.

Governments already have wiretapping laws.  Do you think they will 
abandon that as a desire?
Many laws on crypto were only relatively recently relaxed.  There's an 
ongoing tussle between security agencies of government and privacy 
advocates over it.  We can't guarantee that within the next 5 years 
that any country wouldn't make it illegal.

It's not like we can claim there's no reasonable expectation to 
consider laws when it comes to crypto.  That's the one area of software 
development where caveats and warnings are stamped over so much code 
and documentation that we can't claim to be unaware it's an issue.

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

try finding some real client app that will swallow that.



> 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.
Maybe there's not much sympathy for prisoners.  That's just one example.

Schools, homes and businesses are also places where there may be deemed 
(by those in charge) a need to monitor activity.



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

Can only decode NULL cipher.

Huawei recently got excluded from bidding for an Australian govt 
contract (a large one) due to concerns over possibility of 
eavesdropping.

Mandating privacy on HTTP will make it easier in some cases (e.g. 
infrastructure) to eavesdrop on non-private communication.


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

Sure.  But as previously discussed, the way it is done results in an 
overall reduction in security.  A "sanctioned" way would be much 
preferable, but necessarily reduces privacy potentially to 0.

And, do we want shared caches to continue to exist?




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

not compared to their revenues is what I meant.
>


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

the thin edge of the wedge.  How can one have any faith in some entity 
vouching for some other entity when no payment is made (therefore no 
rigorous check can be made).




> 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!
I'm sure it can be made a lot easier.

I think maybe even it could be made easy enough for my mom to do it on 
her DSL modem web interface... er... maybe not....



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

I foresee a problem where OSes have too many trusted root certs to 
manage.  The more CAs and trusted root certs we end up with, the larger 
the attack surface for anyone trying to inject badness into the system.

No-one surely needs reminding about the recent CA breaches and bad 
certs issued.

Security is only as strong as the weakest link, which is invariably us. 
  I don't know what we're aiming for, security or a false sense of it.


> 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.
I'd love to fix it.  Not sure how though.



> 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.
verifiable independently?  With certs?  How do you check those?

Or do we rely on DNS for that?




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

The current situation is really that bad?


>


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

My main issue is not with security or privacy, but only relating to 
mandating the USE of it.

Adrien


>
>Mike

>