[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <520C81B9.6000001@redhat.com>
Date: Thu, 15 Aug 2013 01:22:33 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: gremlin@...mlin.ru
Subject: Re: HTTPS
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/15/2013 12:38 AM, gremlin@...mlin.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-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
