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

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

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




>
>
>
> Sites that are truly concerned can still negotiate the null cypher, I
> suppose.
>
>
> try finding some real client app that will swallow that.
>

you are right :-)


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

But schools have bigger problems - like those cell phones with more
bandwidth than the school has to its classrooms.

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.

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.



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



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



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



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


>
> 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.  Personally, the security risks of using such a proxy
probably outweigh the performance advantages for most people.  This is
similar in concept to what Douglas Beaver articulated so well in a separate
thread.

Mike






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