oss-sec mailing list archives
Re: HTTPS
From: Donald Stufft <donald () stufft io>
Date: Thu, 15 Aug 2013 06:40:14 -0400
On Aug 15, 2013, at 6:31 AM, gremlin () gremlin ru wrote:
On 15-Aug-2013 01:22:33 -0600, Kurt Seifried wrote:everyone should be enabling HTTPS where possible,Very dangerous mistake. HTTPS should be used only for non-anonymous access, otherwise plain HTTP is preferred. In any case, let the users choose whether they want to use it.This is literally the first time I've ever heard anyone say this, I'm curious though, can you explain your reasoning/evidence for this statement?The reasoning is simple: 1. Not all interceptions and modifications are evil. 2. Some sites are much more evil than interceptors.
#1 is technically true but because there's no way to programmatically determine if a interception or modification is "evil" systems should default to disallow and allow the user to allow it (by trusting another CA for instance for the interceptor). I don't understand how #2 relates to HTTPS at all, TLS doesn't state anything about the safety of the server you're connecting to only the safety of the transport.
You do realize HTTPS can be just as "anonymous" (ignoring the fact you have the persons IP/time stamp, browser string, etc =) as normal HTTP.Yes. And, just in case: HTTPS is used to bypass content-filtering proxies (ones that cut ads|malware|etc).
This is a false dichotomy. There are plenty of ways to do content-filtering proxies with HTTPS in a way that will still work.
Compare to FTP vs SCP/SFTP: first is for getting files from anyone (into /incoming) and giving files for everyone (from /pub), second is for transferring your own files. Obviously, I presume FTP daemon to be configured for anonymous-only access.Now I'm just confused.Why?intercepting and modifying HTTP is trivial.Yes. But intercepting and modifying HTTPS requires just an ability to issue client-trusted certificates (sufficient for 99% of HTTPS applications), so the content signing should always be preferred over distributor validation.And now I'm seriously confused. For clients that do not validate hostnames it would be true that you could get an HTTPS cert for any domain name and use it,The valid HTTPS certificate doesn't mean getting valid content - it only means you've connected to (most likely) the right server.
It means you've connected to the right server and no attacker in the middle has modified the data (nor can they see the data). It makes no assertion about if the data the server gave you is correct, it only protects the transport.
this would also work for the case where you first use HTTP to get a redirect to HTTPSThe most annoying behavior... Should be used only when the visitor wants to log in. IMHO.
This doesn't reflect the state of browser security. You basically need forced HTTPS or a number of attacks are possible against a typical site.
(the attacker intercepts the HTTP and sends you to an attacker controlled HTTPS).Unlike SSH, the HTTPS clients (which usually are the browsers) do not cache the visited servers' certificates, fully relying on issuing CA's honesty. This introduces a risk of false sence of security. Hmmmm... It seems that keeping self-signed certificates is even more safe than relying on "trusted" CAs…
Or you can use public key pinning via headers like "Public-Key-Pins", or TLS extensions like TACK. And if you don't want to trust the CAs there are also solutions like convergence.
Hence ALWAYS using HTTPS!Ok. But NEVER force the visitors of your site to use it :-)
Completely disagree. HTTPS should by the default and all traffic should be forced over it.
I really suspect you have misunderstood what encrypted network protocols are for. Typically they address three major problems: integrity (attackers modifying traffic en route), confidentiality (by encrypting it)Do public data really need that?
Just because data is public doesn't mean you don't want to be assured that nobody has modified the data between the server and your computer. It also completely misses the fact that just because data is public it doesn't mean you want third parties to be able to see that you're accessing that data.
and as an offshoot of these two properties, and the magic of key exchanges you can also handle authentication securely, if desired.How many sites do use the HTTPS client certificates for authentication? My estimation: less than 1%, as most use trivial username + password over the encrypted connection. -- Alexey V. Vissarionov aka Gremlin from Kremlin <gremlin ПРИ gremlin ТЧК ru> GPG key ID: 0xEF3B1FA8, keyserver: hkp://subkeys.pgp.net GPG key fingerprint: 8832 FE9F A791 F796 8AC9 6E4E 909D AC45 EF3B 1FA8
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
Current thread:
- Re: rubygems insecure download (and other problems), (continued)
- Re: rubygems insecure download (and other problems) Henri Salo (Aug 15)
- Re: rubygems insecure download (and other problems) Kurt Seifried (Aug 15)
- RE: rubygems insecure download (and other problems) Christey, Steven M. (Aug 15)
- Re: HTTPS (was: rubygems insecure download (and other problems)) gremlin (Aug 14)
- Re: HTTPS (was: rubygems insecure download (and other problems)) Donald Stufft (Aug 14)
- Re: HTTPS (was: rubygems insecure download (and other problems)) Pavel Labushev (Aug 16)
- Message not available
- Re: HTTPS Kurt Seifried (Aug 21)
- Re: HTTPS Pavel Labushev (Aug 22)
- Re: HTTPS (was: rubygems insecure download (and other problems)) Donald Stufft (Aug 14)