1438713 - Consider expanding HSTS to apply to FTP

Status: RESOLVED WONTFIX

(Core Graveyard :: Networking: FTP, enhancement, P3)

Description

[Jonathan Kingston [:jkt] he/him]

When the browser encounters a FTP URL it should treat it in the same way as the browser does for HTTP links that are in the browsers HSTS list.

The idea is that websites can then protect themselves from spoofing over ftp whilst helping adopt HSTS and deprecate FTP.

If the change is a success this would need a specification change.

April has done some studies for this which suggests .03% of the top 1M sites would be impacted by this change.

Comment 1

[April King [:April]]

Here are the statistics based on my testing:

Of the Alexa Top 1 Million Websites (as of February 1, 2018):

Successful scans: 976,930
Sites that use HSTS: 81768 (8.4%)
Sites that use HSTS and have FTP on their host *or* use HSTS + includeSubDomains and have ftp://ftp.host/: 297 (.36% of HSTS using sites, .03% of the top 1M sites)

The 10 largest sites that meet these conditions are:

wiley.com (#404)
cdc.gov (#1540)
videolan.org (#2876)
asstr.org (#9116)
up.pt (#9737)
ietf.org (#9973)
osdn.net (#11986)
penguinrandomhouse.com (#14306)
iinet.net.au (#15196)
ego4u.com (#16400)

I've attached the complete list to the bug. The columns are:

1. hostname
2. whether ftp://host/ works
3. whether ftp://ftp.host/ works, if and only if they have HSTS + includeSubDomains set

Given the relatively low rankings, I would expect that blocking FTP from sites that have set HSTS would be likely to have a pretty low impact. For example, I just checked videolan.org and although they are available over FTP, their downloads come over http and/or https. wiley.com has ftp, but hasn't had a file updated there since 2016 and most of them are far older.

cdc.gov does seem to use it, but, as far as I can tell, does not support ftps or sftp.

The IETF FTP mirror seems to mirror the content (but not the organization) of the website. 


There are a bunch of things to take into consideration here:

1. Many of these sites have FTP servers running, but they're not actually used for anything
2. This only indicates if ftp://host/ works. Given that FTP has no virtual hosting, there is a high likelihood that many of these are simply FTP servers running on the same host as the website, but don't belong to that website.
3. There are likely to be internal FTP servers that this would impact, where ftp://ftp.host/ works, but only if you are trying to access it from inside their network or from specific hosts.

Some other information of note. As of August 2017, FTP accounted for only .0026% of all Chromium top-level navigations:
https://groups.google.com/a/chromium.org/d/msg/security-dev/HknIAQwMoWo/xYyezYV5AAAJ

I can get updated Chromium numbers if you like, but I have to imagine that it has only trended down since then. Given all that, if we do enable an FTP + HSTS flag, it would also be nice if we could add a flag to disable FTP entirely.

Comment 2

[April King [:April]]

Attachment: Results of connecting over FTP to sites with HSTS

Comment 3

[Jonathan Kingston [:jkt] he/him]

> it would also be nice if we could add a flag to disable FTP entirely.

We have the pref already implemented in Bug 1374114 "network.ftp.enabled"

I don't think we have stats for subresource scheme loading of ftp, eitherway it's pretty clear here that the breakage will be limited to a very few number of sites. We have a few other things to get to where we would flip this just yet however I think this makes sense for the short term especially if the implementation is small.

Comment 4

[April King [:April]]

BTW, I'm talking to folks at the IETF to enable:

https://ftp.ietf.org/

As a mirror of:

ftp://ftp.ietf.org/

In much the same way we have https://ftp.mozilla.org/pub/

Comment 5

[Valentin Gosu [:valentin] (he/him)]

Jonathan, I hope you don't mind if I assign this to you for now (for triaging purposes)

Comment 6

[Jonathan Kingston [:jkt] he/him]

That is fine Valentin!

My initial investigation into this suggests we need to add an interrupt channel handler much like HTTP has for HSTS upgrades. This looks a little more involved that my initial hunch was (however not surprised based on my success of getting console logging working for FTP). P3 is likely the right priority too, I'm not planning on working on this until next quarter unless I finish other work sooner.

Comment 7

[ExE Boss]

This likely depends on bug 85464, as not all FTP servers are mirrored over HTTP(s), but they might support FTPS.

Comment 8

[ExE Boss]

(In reply to April King [:April] from comment #4)
> BTW, I'm talking to folks at the IETF to enable:
> 
> https://ftp.ietf.org/
> 
> As a mirror of:
> 
> ftp://ftp.ietf.org/
> 
> In much the same way we have https://ftp.mozilla.org/pub/

What about ftps://ftp.ietf.org/ or ftps://ftp.mozilla.org/pub/ ?

Comment 9

[Darkspirit]

I don't think this is funny: ftp://terrax.net/index.html ;D

Comment 10

[Darkspirit]

For WhatsApp: https://bit.ly/2Pev7qb

Comment 12

[Mathew Hodson]

I think this can be closed as WONTFIX since FTP support was removed in bug 1574475.

Comment 13

[Mathew Hodson]

Actually, I think I misinterpreted the suggestion just based on the bug title.

This seems like it's similar or maybe a duplicate of bug 1706271.

Comment 14

[Jens Stutte [:jstutte]]

(In reply to Mathew Hodson from comment #13)

Actually, I think I misinterpreted the suggestion just based on the bug title.

This seems like it's similar or maybe a duplicate of bug 1706271.

I'd say, after removing FTP support, this is actually a WONTFIX but bug 1706271 is still a good path forward for some users.