[sf-lug] misinformation [was: Re: https hack]

[Asheesh Laroia]

As a clarification here, the attack does expose URL paths e.g. /foo in
https://example.com/foo (if I understand the attack correctly), whereas
hostnames were already exposed due to SNI.

HTTPS's protection of URL paths is important for HTTPS applications that
use "capability URLs". Apps that use capability URLs include:

- Dropbox

- Google Docs

- Etherpad

- Sandstorm

- Any app that uses password reset links

- GitHub in "gists"

and so forth.

As for the rest of your comment, Michael:

On Tue, Aug 23, 2016 at 12:06 AM, Michael Paoli <
Michael.Paoli at cal.berkeley.edu> wrote:

> I've certainly got to agree with others, that some of the
> misinformation that some of the "tech press" puts out
> is quite appalling - and that probably applies double or
> more to security related articles.
>
> For example this one:
>
> To: sf-lug <sf-lug at linuxmafia.com>
>> Subject: [sf-lug] https hack
>> Date: Sat, 30 Jul 2016 10:01:57 -0700
>>
>
> New attack bypasses HTTPS protection on Macs, Windows, and Linux<
>> http://arstechnica.com/security/2016/07/new-attack-that-
>> cripples-https-crypto-works-on-macs-windows-and-linux/
>>
>
> The article starts of with, very first sentence of the very first
> paragraph:
> "A key guarantee provided by HTTPS encryption is that the addresses of
> visited websites aren't visible to attackers who may be monitoring an end
> user's network traffic."


I agree that this is sloppy, confusing writing - domain names for HTTPS
requests are already exposed, and IP addresses *certainly* are already
exposed by TCP/IP underneath HTTPS.

Good further reading for those who want to learn more:

- https://https.cio.gov/faq/

-
http://stackoverflow.com/questions/8858102/with-https-are-the-url-and-the-request-headers-protected-as-the-request-body-is

Cheers,

Asheesh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20160823/101a9031/attachment.html>