Re[4]: 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 9:51 PM, Adrien W. de Croy <adrien@qbik.com> wrote:
> 
> ------ 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.
 
 Agree; goal should be to be better.  That doesn't mean that I think 
 everyone will jump to it in short order, though. 
I don't expect anything to be jumped to in short order.





> > 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.
>
>
>Well, when you've got a specific country to talk about, please raise 
>the issue.
Maybe someone from one of the countries I listed above would be in a 
better position to comment than I am.

>


> > 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.
 
 They already have this problem.  Twitter, Google, and Facebook have 
 all publicly declared that they are working their way to 100% TLS all 
 the time.  These issues exist today.  If you want to filter TLS, you 
 can; several vendors provide solutions.
Sure, and as said before, this is not without security implications.

>
>But schools have bigger problems - like those cell phones with more 
>bandwidth than the school has to its classrooms.  
Many schools ban cellphones.  My son's school does.

>
>I don't think the protocol has an obligation to reduce security so 
>that prisons, schools, or other institutions can institute content 
>control.   And by the time this standard is done, the policy rules 
>will have changed again.

I'm not proposing we take the current level of security of HTTP/1.1 and 
reduce it.

you're proposing we add TLS.  Whilst that will provide a level of 
privacy in many cases, I don't think it will overall result in an 
improved security situation overall, especially if it breaks SSL/TLS.  
I kinda like SSL/TLS, I'd like it to continue to be usable.
>
>A simple thing we do know is that users expect and deserve to be 
>protected by the protocols and sites they visit.  We're passing more 
>laws every day to ensure this - and HTTP can help.

rubbish, we know no such thing.

all users are not equal.  All users are not equally deserving of 
privacy in all situations.


>




> > 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.
 
 With wireshark you can decide SSL session if you let your browser dump 
 the private keys.  Chrome supports this.  http://www.imperialviolet.org/2012/06/25/wireshark.html


OK, well let's hope we never have to debug any protocol - level stuff 
with any other client software.

>


> Huawei recently got excluded from bidding for an Australian govt 
> contract (a large one) due to concerns over possibility of 
> eavesdropping.
 
 Excellent point for why we should make the protocol more secure :-)  
 If everything were encrypted, it wouldn't have been a problem. 
Sure, anything sensitive should be encrypted before it goes over that 
infrastructure.  But I'm sure some large equipment vendor was lobbying 
somewhere.
>


> Mandating privacy on HTTP will make it easier in some cases (e.g. 
> infrastructure) to eavesdrop on non-private communication.
 
 What?  Mandating privacy makes it easier to eavesdrop?  I don't think 
 so :-)

sure it does.  How can you tell if something is spyware or 
eavesdropping on you if you can't see if the phone home data is a 
version check or a report of your activity because it's encrypted?

If my phone-home data is plaintext HTTP, I can demonstrate it's not 
eavesdropping.

>



> > 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.
 
 I disagree that it takes privacy to zero. 
I said potentially.  If you let your company see your data because they 
operate the proxy that terminates the SSL connection from the browser, 
then your expectation of privacy (from your company) is potentially 0.

Companies will continue to insist on scanning or blocking. 
> The end user will be aware of such changes; these are only possible 
>by changing the trust points in the browser.  If your company gives 
>you a browser, it can change your trust points.  But if it is your own 
>browser, you pick the trust points.
>
>I agree this is obscure, but it is something we can improve upon.  I 
>agree that we should.
>
>Until we turn on SSL for everyone, it won't likely get improved.

Yeah I dunno, I think we could improve it independently of that.



> And, do we want shared caches to continue to exist?
 
 Of course we do.  We switch to opt-in proxies (like what Roberto Peon 
 has proposed) rather than the transparent proxies that we have today.  
 These are much better because the user has the opportunity to know the 
 proxy is there, unlike today.  
We've been recommending against using transparent proxying for years.  
Unfortunately that doesn't reduce demand for it.

proxy discovery needs to be greatly improved.

But even with explicit proxy use by the client, for SSL/TLS that just 
boils down to HTTP CONNECT, which bypasses the proxy anyway.

>Personally, the security risks of using such a proxy probably outweigh 
>the performance advantages for most people.

Using a home or corporate proxy has security risks that outweigh 
benefits of shared cache and scanning????

Problem is, the people who operate these proxies think differently to 
you.  They want to see and scan everything.  They don't care so much 
about privacy on their LAN. 

They also may pay for data, so they want to cache.

Wireless hotspots is a different issue of course, something needs to be 
done about that.

>  This is similar in concept to what Douglas Beaver articulated so 
>well in a separate thread.
>



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

 >
>