PSA: `ftp://` resources will be marked "Not Secure"

[Mike West]

BCCing blink-dev@ for visibility.

Hello, security-dev!

As part of our ongoing effort to accurately communicate the transport security status of a given page, we're planning to label resources delivered over the FTP protocol as "Not secure", beginning in Chrome 63 (sometime around December, 2017).

We didn't include FTP in our original plan, but unfortunately its security properties are actually marginally worse than HTTP (delivered in plaintext without the potential of an HSTS-like upgrade). Given that FTP's usage is hovering around 0.0026% of top-level navigations over the last month, and the real risk to users presented by non-secure transport, labeling it as such seems appropriate.

We'd encourage developers to follow the example of the linux kernel archives by migrating public-facing downloads (especially executables!) from FTP to HTTPS.

Thanks!

-mike

[abor...@gmail.com]

On Thursday, September 14, 2017 at 1:19:28 AM UTC-7, Mike West wrote:
> BCCing blink-dev@ for visibility.
> Hello, security-dev!
>
> As part of our ongoing effort to accurately communicate the transport security status of a given page, we're planning to label resources delivered over the FTP protocol as "Not secure", beginning in Chrome 63 (sometime around December, 2017).
>

> We didn't include FTP in our original plan, but unfortunately its security properties are actually marginally worse than HTTP (delivered in plaintext without the potential of an HSTS-like upgrade). Given that FTP's usage is hovering around 0.0026% of top-level navigations over the last month, and the real risk to users presented by non-secure transport, labeling it as such seems appropriate.
>
> We'd encourage developers to follow the example of the linux kernel archives by migrating public-facing downloads (especially executables!) from FTP to HTTPS.

No mention of FTPS, so I assume this won't be flagged. The statement was somewhat vague on this.

[Eric Lawrence]

Chrome does not implement FTPS.

-Eric

[Armando Ortiz]

Ahh...did not know this.  Thanks!

[jameswri...@gmail.com]

So more like "could be secure on ftps but marking ftp traffic not secure is easier than supporting secure ftp"

[PhistucK]

No, more like - no major browser supports FTPS.

Does any browser at all support FTPS at the moment?

☆PhistucK

On Thu, Sep 14, 2017 at 8:17 PM, <jameswri...@gmail.com> wrote:

So more like "could be secure on ftps but marking ftp traffic not secure is easier than supporting secure ftp"

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

[Thomas Sepez]

As opposed to removing FTP entirely given that usage and because it isn't the 1970s anymore ?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcidWHObZPx_uuFLdk3KoJxYv5N8aMZNXHRBygveP5CuA%40mail.gmail.com.

[Chris Palmer]

Because FTP usage is so low, we've thrown around the idea of removing FTP support entirely over the years. In addition to not being a secure transport, it's also additional attack surface, and it currently runs in the browser process. (Do we have any fuzzers for it?)

I would much rather remove FTP support for these reasons.

On Thu, Sep 14, 2017 at 1:19 AM, Mike West <mk...@chromium.org> wrote:

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

[mco...@gmail.com]

Please *do* get rid of all FTP support in CHROME... that will allow the FTP-CLIENT and FTP-SERVER software that I create, to be sold more. (builtbp.com)

:P

It's false to assume that FTP|FTPS is *not* used anymore. While smaller than web-traffic, it's still a staple of file transfers. Besides, is this really a fair comparison?

FTPS is a completely viable and secure protocol, while stateful and difficult to code, it's just as secure as HTTPS. Chrome *is* a web-browser, so I understand the need to only support what it's intended.

SFTP is another story, one in which browsers should never support IMHO.

On Thursday, September 14, 2017 at 10:27:16 AM UTC-7, Chris Palmer wrote:
> Because FTP usage is so low, we've thrown around the idea of removing FTP support entirely over the years. In addition to not being a secure transport, it's also additional attack surface, and it currently runs in the browser process. (Do we have any fuzzers for it?)
>
>
> I would much rather remove FTP support for these reasons.
>
>
> On Thu, Sep 14, 2017 at 1:19 AM, Mike West <mk...@chromium.org> wrote:
>
> BCCing blink-dev@ for visibility.
>
>
> Hello, security-dev!
>
>
> As part of our ongoing effort to accurately communicate the transport security status of a given page, we're planning to label resources delivered over the FTP protocol as "Not secure", beginning in Chrome 63 (sometime around December, 2017).
>
>
>
>
>
>

> We didn't include FTP in our original plan, but unfortunately its security properties are actually marginally worse than HTTP (delivered in plaintext without the potential of an HSTS-like upgrade). Given that FTP's usage is hovering around 0.0026% of top-level navigations over the last month, and the real risk to users presented by non-secure transport, labeling it as such seems appropriate.
>
>
> We'd encourage developers to follow the example of the linux kernel archives by migrating public-facing downloads (especially executables!) from FTP to HTTPS.
>
>
> Thanks!
>
>
>
> -mike
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "Security-dev" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Eric Lawrence]

The proposal to remove support for FTP entirely is tracked in https://crbug.com/333943.

-Eric

[Matthew Menke]

Is there any security badging for FTP downloads, as opposed to FTP directory listings or rendered resources?

[Matthew Menke]

Sorry, that should be "is there any planned security badging"?

[Chris Palmer]

On Thu, Sep 14, 2017 at 10:36 AM, <mco...@gmail.com> wrote:

It's false to assume that FTP|FTPS is *not* used anymore. While smaller than web-traffic, it's still a staple of file transfers. Besides, is this really a fair comparison?

The only claim we're making is that "FTP's usage is hovering around 0.0026% of top-level navigations over the last month", based on our UMA metrics. When a feature gets usage that low, we generally start talking about removing it. Especially if it exposes attack surface or is fundamentally unsafe on the network, as FTP does and is.

As for FTPS, I'm glad it exists, but if we were going to focus on getting server operators to migrate to a new protocol, we would focus (and are focusing) on HTTPS.

[Mike West]

In order to make a reasonable decision about whether removing FTP from Chrome is the right path forward, it would be helpful to understand how many FTP downloads users generally trigger. I've only looked into numbers for top-level navigation (`Navigation.MainFrameSchemeDifferentPage`), which I don't believe includes downloads. I didn't find a similar metric breaking downloads out by scheme; perhaps someone could point me in the right direction?

A middle ground which I'd like to see us pursue in the near term is to force download rather than rendering of FTP resources (https://crbug.com/744499). That's less drastic, but would allow us to make some small changes to simplify Blink's code (we could stop treating `ftp` as a standard scheme with a non-unique origin, we could stop allowing `ftp` sites to have cookies, etc.). None of that is world-changing, but simplification is simplification.

All of that, however, is unstaffed dreaming at the moment: today, all I'm planning on doing is changing the way we label the connection status. If/when we want to make broader decisions about FTP's web-facing behavior, we'll do so via Intent threads on blink-dev@. :)

-mike

[Mike West]

On Fri, Sep 15, 2017 at 8:41 AM, Mike West <mk...@chromium.org> wrote:

In order to make a reasonable decision about whether removing FTP from Chrome is the right path forward, it would be helpful to understand how many FTP downloads users generally trigger. I've only looked into numbers for top-level navigation (`Navigation.MainFrameSchemeDifferentPage`), which I don't believe includes downloads. I didn't find a similar metric breaking downloads out by scheme; perhaps someone could point me in the right direction?

Of course, as soon as I sent this, I found `Download.TargetConnectionSecurity`, which shows that ~4.73% of downloads over the last month are using a non-HTTP(S) scheme. I think that might be an overestimate for `ftp:`, as it's not clear to me where `blob:` or `filesystem:` get bucketed, but it's a useful upper-bound on FTP traffic. +elawrence@, who might know off the top of his head?

[Eric Lawrence]

You're right that Navigation.MainFrameSchemeDifferentPage does not include downloads and Download.TargetConnectionSecurity records blob: downloads as DOWNLOAD_NONE_HTTPX lumping them in with FTP and FILE. 

It probably makes sense to fix up RecordDownloadConnectionSecurity so that it tracks redirection chains properly when the final URL is FTP and so that it explicitly logs downloads from FTP. 

-Eric

[Hanno Böck]

Hi,

One question: Does this also imply that FTP connections will be blocked
on HSTS domains?

I find this actually a quite surprising property of HSTS that you can
still have plaintext connections to that host via FTP. Appart from
phishing / social engineering I'm not aware of any concrete attack
scenarios, but I still feel this is very undesirable and should be
stopped.

It has been discussed before, but the bug was closed wontfix:
https://bugs.chromium.org/p/chromium/issues/detail?id=551468

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Eric Lawrence]

The change (https://chromium.googlesource.com/chromium/src.git/+/3c82f58d3cb10286362992a01b2254e6066edb36) doesn't impact HSTS. 

Notably, FTP has always been treated as non-secure (so e.g. password fields in HTML served by FTP triggered the Not Secure warning starting in Chrome 56), the proposal and change here simply mark FTP as non-secure even without any sort of user-action. Eventually HTTP will do the same.

-Eric

[Mike West]

As Eric notes, the change doesn’t affect hosts that have opted into HSTS. That's not terribly surprising, given the initial "H", but perhaps we count extend the definition to match the header (`Strict-Transport-Security`) rather than the RFC's name.

It wouldn't be tough to walk through the HSTS preload list to see how many of those registrable domains also hosted publicly-accessible FTP servers. I'm pretty sure `google.com` does, for example at `uploads.google.com`, though I don't think folks expect to access that via the browser. Would you be willing to gather some metrics?

*shrug* I would not be sad if we blocked FTP for domains that have opted into HSTS (and palmer@'s old patch shows that it's a fairly trivial change), though I think I'd prefer to just stop supporting FTP entirely. We're gathering metrics to evaluate that latter option.

-mike