Opened 8 years ago

Closed 8 years ago

#3368 closed enhancement (fixed)

Add *.torproject.org to Chrome STS list

Reported by: cypherpunks Owned by: phobos
Priority: Medium Milestone:
Component: Webpages/Website Version:
Severity: Keywords:
Cc: tagnaq@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I think we should help Chrome users download Tor safely by adding Tor's servers to the Chrome preloaded STS list:
http://dev.chromium.org/sts

The first step is probably to add HSTS headers to all of our TLS servers and the second is to identify any hosts that _do not_ support TLS.

Child Tickets

Change History (8)

comment:1 Changed 8 years ago by phobos

Cc: weasel karsten runa phobos ioerror removed
Component: - Select a componentWebsite
Resolution: wontfix
Status: newclosed

Chrome should honor the existing STS headers on our sites. We shouldn't need to add to some special list deep inside chrome. There is already a ticket to add STS to our sites, see #2613

comment:2 Changed 8 years ago by tagnaq

Cc: tagnaq@… added

AFAIK Chrome honors STS headers. Shipping a list with a browser protects also user who access a certain website for the first time. Users without such a list remain vulnerable against active MITM attackers.

I would see the use of the list within chrome similar to the list in the HTTPSEverywhere firefox addon. (where the torproject seams to be included)

btw: https://deb.torproject.org redirects to the main page (www)

comment:3 Changed 8 years ago by cypherpunks

I want to protect Chrome users who have not ever connected to the site. I plan on submitting a patch to Chrome for www.torproject.org as it appears to be safe to do so.

comment:4 Changed 8 years ago by phobos

Resolution: wontfix
Status: closedreopened

Having read the draft standard on ietf's site, and now looking through the chromium sts list. This appears to be nothing more than the equivalent of our firefox extension https everywhere for chromium. For the vast majority of users, great, they can get to our https-enabled sites by default.

If the user has never visited *.torproject.org, doing so over https isn't going to stop an ssl mitm. Correct?

comment:5 in reply to:  2 Changed 8 years ago by phobos

Owner: set to phobos
Status: reopenedaccepted

Replying to tagnaq:

btw: https://deb.torproject.org redirects to the main page (www)

Correct. deb.tpo is a round-robin dns for a few different servers. We don't want to give all mirrors the ssl cert.

comment:6 in reply to:  4 Changed 8 years ago by phobos

Replying to phobos:

If the user has never visited *.torproject.org, doing so over https isn't going to stop an ssl mitm. Correct?

Thinking further about this, it's the same problem I have with our https everywhere firefox extension, unless you include the ssl fingerprints and serial numbers, how does the user know that the cert that is presented is the correct cert?

comment:7 Changed 8 years ago by cypherpunks

It will stop anyone who tries to do an sslstrip attack and that is the purpose. Anyone with a valid CA will be able to perform a MITM and in the future, Chrome will have DNS binding that allows you to say _which_ CA will be able to sign for your domain. So in the very near future, this will actually prevent most MITM attacks and right away it will prevent downgrade attacks.

If the user has torproject.org in the list, the website will simply break and hopefully they will email us. That seems like a fine failure mode and we can't really help them unless they do contact us.

comment:8 Changed 8 years ago by phobos

Resolution: fixed
Status: acceptedclosed

Our sites all have sts headers now. it's up to google to put our sites into their special sts sitelist.

Note: See TracTickets for help on using tickets.