W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Moving forward on improving HTTP's security

From: Roland Zink <roland@zinks.de>
Date: Thu, 14 Nov 2013 11:24:08 +0100
Message-ID: <5284A4C8.70102@zinks.de>
To: ietf-http-wg@w3.org
What will be the goal of mandating TLS?
  1) Is it end to end security?
  2) Is it just securing the connection to the next hop?

If it is 1) how can proxy based services like virus scanning and caching 
be done?
If it is 2) how is end to end security achieved?

Regards,
Roland


On 14.11.2013 10:34, Adrien de Croy wrote:
> ------ Original Message ------
> From: "William Chan (ι™ˆζ™Ίζ˜Œ)" <willchan@chromium.org 
> <mailto:willchan@chromium.org>>
>> On Wed, Nov 13, 2013 at 2:36 PM, Adrien de Croy <adrien@qbik.com 
>> <mailto:adrien@qbik.com>> wrote:
>>
>>
>>     We added MITM in WinGate mostly because Google and FB went to
>>     https.  Google and FB you may take a bow.
>>
>>
>> FWIW, I'm happy those companies went HTTPS, and I'm sad that y'all 
>> are offering MITM features in your products. I suppose that if I ask 
>> you not to MITM traffic, you wouldn't listen, would you? :P If you 
>> feel that MITM is bad for the web, why are you implementing this? Is 
>> it simply because if you don't, then someone else will and people 
>> will switch from your product?
> we only write the proxy software and provide the feature. The customer 
> decides whether to turn it on or not.
> The customers have been asking for this feature for years. We held 
> off, but had to concede when Google and FB went to https, as the rate 
> of requests went up.  Much of the competition had been offering it for 
> several years.
> So do you really think the vendor company that steadfastly refuses 
> to offer it will be the one left standing?  There are already plenty 
> of vendors offering this feature.  It's a competitive necessity.
>>
>>
>>     Does this improve security of the web overall?  IMO no.  People
>>     can now snaffle banking passwords with a filter plugin.
>>
>>
>> Just to be clear, the MITM works because the enterprises are adding 
>> new SSL root certificates to the system cert store, right? I agree 
>> that that is terrible. I wouldn't use that computer :) I hope we 
>> increase awareness of this issue.
> correct.  You can tell if you're being intercepted if the root cert 
> doesn't look like who it should be.
>>
>>
>>     You really want to scale this out?  How will that make it any better?
>>
>>
>> I believe that making communications secure by default will overall 
>> improve the security of the web as long as most devices don't have 
>> these additional SSL root certificates used by the MITM proxies. You 
>> are taking a cynical view on the outcome when communications become 
>> secure by default. I disagree.
> I'm not talking about a hypothetical future.  We're seeing it now.  
> More and more MITMs are being deployed.  That's not a cynical or 
> pessimistic view, it's simply accepting reality.
>> I think that it's worthwhile to force entities that want to examine 
>> communications to have to MITM SSL. I think that the negative PR of a 
>> government or ISP or whatever trying to force installations of 
>> additional root certificates on end users' machines would be a strong 
>> disincentive to employ these policies. I agree it might lead more 
>> enterprises to MITM their employees who use corporate devices. It is 
>> a sad world indeed if it's the status quo for everyone to use devices 
>> with extra root certs so intermediaries can MITM SSL connections.
> Many people operating these things don't get a choice.
> Try telling a company boss that they shouldn't care if their employees 
> cyber-slack all day because you can't tell what they are surfing.  
> Tell them they shouldn't care if their employees download malware and 
> infect their networks because they can't scan it for viruses.
>>
>>
>>     You're suggesting anyone wanting to run an http2 server now has
>>     to purchase, and pay for the ongoing maintenance of a cert, and
>>     take the cost on additional CPU to handle the load?
>>
>>
>> Yes, I want to use HTTP/2 as a carrot to incentivize server operators 
>> to use HTTPS. There are tradeoffs that prevent folks from adopting 
>> HTTPS. I'm hoping HTTP/2 helps adjust the tradeoffs in HTTPS' favor 
>> somewhat, due to its reduced user perceived latency and improved 
>> connection reuse leading to improved scalability compared to HTTP/1.X 
>> over TLS.
>>
>>
>>     Organisations have to live with the pain in the neck of deploying
>>     signing certs to clients, dealing with visitor devices etc etc.
>>      This = reduction in user experience.
>>
>>
>> You mean the additional root certs installed on client machines? 
>> Good, I'm glad it's a PITA for y'all, so maybe you'll stop doing it 
>> or do it less often, and maybe corporations will stop asking you to 
>> do this for them.
> And maybe not.  You really think corporates are going to stop caring 
> about these things?  They are caring more and more, not less and less.
> If everyone had a realistic choice, they could choose to stop MITM, 
> but malware using https put paid to that.  The argument has already 
> been put about the necessity of caching, that you'd presumably also be 
> happy to throw under the bus.
>> This is terrible and I'm personally not interested in making it 
>> easier for organizations to snoop on their 
>> members/employees/students/etc.
> make sure you're not making incorrect assumptions about this so-called 
> "snooping".  Is it really snooping if the only thing that sees the 
> data is an AV agent?
>> I'm in favor of reduced user experience where the user is someone who 
>> wants to MITM SSL traffic.
> I'm also in favour of it being visible to the user whether they are 
> being intercepted MITMed.
> Regards
> Adrien
>>
>>
>>     So, IMO making TLS mandatory = reduced security, worse user
>>     experience, and increased costs.
>>
>>     That's progress I guess.
>>
>>
>> I respectfully disagree with your outcome prediction.
>>
>>
>>
>>
>>
>>
>>     ------ Original Message ------
>>     From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie
>>     <mailto:stephen.farrell@cs.tcd.ie>>
>>     To: "Willy Tarreau" <w@1wt.eu <mailto:w@1wt.eu>>; "Mike Belshe"
>>     <mike@belshe.com <mailto:mike@belshe.com>>
>>     Cc: "William Chan (?????????)" <willchan@chromium.org
>>     <mailto:willchan@chromium.org>>; "Tao Effect"
>>     <contact@taoeffect.com <mailto:contact@taoeffect.com>>; "Tim
>>     Bray" <tbray@textuality.com <mailto:tbray@textuality.com>>;
>>     "James M Snell" <jasnell@gmail.com <mailto:jasnell@gmail.com>>;
>>     "Mark Nottingham" <mnot@mnot.net <mailto:mnot@mnot.net>>; "HTTP
>>     Working Group" <ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>>
>>     Sent: 14/11/2013 10:57:46 a.m.
>>     Subject: Re: Moving forward on improving HTTP's security
>>
>>
>>         I have to agree that the logic here is hard to find.
>>
>>         On 11/13/2013 09:54 PM, Willy Tarreau wrote:
>>
>>              On Wed, Nov 13, 2013 at 01:23:41PM -0800, Mike Belshe wrote:
>>
>>                  To paraphrase, you're saying:
>>                     "I don't like TLS because I use the presence of
>>                 TLS to know that I could
>>                  be hacked right now. But if you turn on TLS always,
>>                 I won't be able to
>>                  tell if I can get hacked."
>>
>>
>>              Huh ? No. I mean "The TLS model is fine for me as long
>>             as it's used where
>>              needed and if it's not abused because I expect all
>>             actors in the chain to
>>              care about security". Let's ensure we don't break that
>>             weak link from the
>>              root CAs to me by making its use mandatory for all
>>             no-value stuff that
>>              nobody cares about and which will make it normal for
>>             everyone to deploy
>>              broken configs and rogue CAs everywhere for the sake of
>>             simplicity.
>>
>>
>>         Break the link by making it mandatory sounds like wild
>>         supposition.
>>
>>         S
>>
>>
>>                  To summarize:
>>                    1) You're happy with the security you get with TLS
>>                 to Paypal now
>>                    2) You're unhappy with that same security (TLS)
>>                 enforced everywhere
>>                  because it is suddenly less secure.
>>
>>
>>              Exactly.
>>
>>                  This is also illogical. We're not changing TLS.
>>
>>
>>              Yes you are. You're not changing the protocol but the
>>             economics and
>>              the actors' motives to deliver certs the proper way.
>>             When certs are
>>              needed to connect to my printer, I doubt I'll have to
>>             order a new
>>              cert every year to connect to it once every 3 years at
>>             most to change
>>              its IP address. Instead the manufacturer will want a 10
>>             years cert,
>>              and since he won't be able to get that, some CAs will
>>             start to offer
>>              this (possibly at a high price). We'll possibly find it
>>             much easier
>>              and cheaper to become a valid CA and to issue certs for
>>             anyone. I'm
>>              sorry but the day I can issue a paypal cert myself and
>>             have my browser
>>              accept it without me having to do anything with its
>>             configuration, I'll
>>              start to get a little bit scared.
>>
>>              Right now it's simple : TLS is annoying to deploy so you
>>             do it where
>>              it matters. It can be free but at least it requires some
>>             care and you
>>              are willing to accept that for the sites you value. Once
>>             you don't
>>              value anymore the certs you are installing and users
>>             start to do wrong
>>              things such as clicking 100 times a day "Ignore this
>>             cert error" because
>>              everyone uses crappy certs, the TLS model will be useless.
>>
>>              Willy
>>
>>
>>
>>
>>
>>
>>
Received on Thursday, 14 November 2013 10:24:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC