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

I won't comment on most of this - I think we've each made our points and
will need to respectfully disagree.  One last point below.

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

>
> ------ Original Message ------
> From: "Mike Belshe" mike@belshe.com
>
>
>
> On Tue, Jul 17, 2012 at 9:51 PM, Adrien W. de Croy < <adrien@qbik.com>
> adrien@qbik.com> wrote:
>
>>
>> ------ Original Message ------
>> From: "Mike Belshe" <mike@belshe.com>mike@belshe.com
>>
>>
>>
>> On Tue, Jul 17, 2012 at 8:25 PM, Adrien W. de Croy < <adrien@qbik.com><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.
>
> 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>
> 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.
>


Aha - this is the crux indeed.  This is the advocated position of the
"people that operate these proxies".

I'm taking the position of the user.  I want the user to be able to know if
someone is spying on them in all cases.   I think censorship and alteration
of content is such a huge risk to us as a free people that we simply cannot
tolerate not knowing who is scanning our lines.  We must must must know it.

I have yet to find a single user that wants their communications to be
sniffed and potentially altered by third parties without their knowledge.
 Do you want that for your own data?

Now, I'm not trying to block the proxy operators you mention.  I just want
the users to be made aware of their presence, so that users can decide for
themselves whether it is ok (because its their boss on their company
computer) or not (because its someone at my telco).

We do have a choice here - safety for the users vs. enabling of transparent
snooping for anyone.

I choose the users 100% of the time.
Mike




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