oss-sec mailing list archives
Re: HTTPS
From: Kurt Seifried <kseifried () redhat com>
Date: Thu, 15 Aug 2013 01:22:33 -0600
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/15/2013 12:38 AM, gremlin () gremlin ru wrote:
On 14-Aug-2013 14:59:12 -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? 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.
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.
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, this would also work for the case where you first use HTTP to get a redirect to HTTPS (the attacker intercepts the HTTP and sends you to an attacker controlled HTTPS). Hence ALWAYS using HTTPS! 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) and as an offshoot of these two properties, and the magic of key exchanges you can also handle authentication securely, if desired. - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJSDIG5AAoJEBYNRVNeJnmTJSsP/2NEp83Rfm6OUNj9Ti7rQFsm ybBae1RsqoMOS0+IUwI67DldrTH/9Zh8JymaAPXrSASVKJ1/ZxbIP6Vg8rP+tDCF OMX3364kZDfF0+UvG0r1X1S9GJLF7GEXEoUT1n8mSQF6vX2k/pIj1clSfSHG6rcZ LX7Fh6v6Zb3PINK9QTzq0cDVAB+0X6PmKaXIVL1155yXuNV4zMenr8pdnVrJJVDS oURISFMMvPsrHT9ziwG9X8bqxfmUNCh77DR5yRHM5Ir/d0gfK7Eg76uyiDPYCKIp 5fpIJcF2ujo2b7uVscQWjspWuTbD3Ns3zDC4VvydzT1W/H3Or98elS2e/5MMxr9K Inhh8giI7jQnyECjIxBygb2gVmu1WBITSpOMfwNtggyIqozoA3ItVMvtG6UZaAXJ 0xq2Qb54eobzzNwgef2lzzq+CVvV7GfkTv1F/EJtzsWlYn0/a3cE/Cuq78uOqTnu wR1R/QvWJDhU0iTKNFUJTySUn3HVVWq9a8rrVOVEZJh4FVi2cU+wUBfUvs1+56Zf hlNDFtDpiawyajNSgZ0ALrLJHozY2Nc9J4r1joEhMG45flf1OyjVrE+qvWqqGNB+ N3fycpRJHite7HN/Y/F4Yz6EuxdYlnbsquwDt7SaAj1HBElGsJeEK1Lp2KkvWe4D 6aSxSVbOoCC0Yg/JjUdL =8cIv -----END PGP SIGNATURE-----
Current thread:
- Re: rubygems insecure download (and other problems), (continued)
- Re: rubygems insecure download (and other problems) Donald Stufft (Aug 14)
- Re: rubygems insecure download (and other problems) Marcus Meissner (Aug 15)
- 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: rubygems insecure download (and other problems) Marcus Meissner (Aug 15)
- Re: rubygems insecure download (and other problems) Donald Stufft (Aug 14)
- 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)