oss-sec mailing list archives
Re: HTTPS
From: gremlin () gremlin ru
Date: Thu, 15 Aug 2013 22:54:08 +0400
On 15-Aug-2013 06:40:14 -0400, Donald Stufft wrote: [In general, I agree with skipped text - the initial reason for starting this subthread was different]
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.
Exactly! Now, the next question is: against _what_ does it protect the transport? For example, if I want to publish something really interesting for list subscribers (say, an image at http://hren.tebe.ru/noise.png which actually is just a random data), then HTTPS will add nothing except our (and all transit) ISPs wouldn't know what did you really downloaded from that server, but http://hren.tebe.ru/noise.png.sig (or just my note that given file has the size of 6895 bytes and its' SHA1 hash is 2542dd740a6030cc8c98ae4d8ab012bec92fce46) together with this signed message will prove its' integrity.
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
... may...
need forced HTTPS or a number of attacks are possible against a typical site.
I think we'd agree that heavily depends on site's logic.
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.
Yes. But signing the sensitive data is much easier and allows that data to be copied elsewhere.
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 don't see any really good reason for _forcing_ that.
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.
Then protect the data, regardless of the communication channel's protection. Untrusted channel may deliver valid data, and trusted channel may deliver invalid data. That's the only idea why I've started this subthread. -- 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
Attachment:
_bin
Description:
Current thread:
- Re: HTTPS (was: rubygems insecure download (and other problems)), (continued)
- 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)
- Re: HTTPS (was: rubygems insecure download (and other problems)) gremlin (Aug 14)
- Re: HTTPS Kurt Seifried (Aug 15)
- Re: HTTPS gremlin (Aug 15)
- Re: HTTPS Jeremy Stanley (Aug 15)
- Re: HTTPS gremlin (Aug 16)
- Re: HTTPS Kurt Seifried (Aug 15)