1193634 - Provide TLS on https://mzl.la/ and set up redirect and HSTS header

Status: RESOLVED FIXED

(Marketing :: Social Media, task)

Description

[sjw]

+++ This bug was initially created as a clone of Bug #882379 +++

https://mzl.la/ is unreachable due to a timeout error.
http://mzl.la/ works well.


This is quite bad. Every short link posted in social media networks, SUMO or elsewhere is vulnerable against MITM attacks.
There are open alternatives like https://yourls.org/


Another thing Mozilla could do here is to ask Bitly to adopt Let’s Encrypt this November to enable SSL for all the customers including Mozilla.

Comment 1

[Kohei Yoshino]

I think Mozilla IT has nothing to do here, because the mzl.la server is owned and managed by bitly.

Comment 2

[April King [:April]]

So it appears that TLS is at least working now:

https://mzl.la/1LG5eZp

Redirects me properly.  However, the API is generating http links (instead of https) by default.  Can we update bitly to fix that?

Thanks!

Comment 3

[Kohei Yoshino]

https://mzl.la/ is using Let's Encrypt. That's awesome!

Comment 4

[sjw]

I get SSL_ERROR_UNSAFE_NEGOTIATION with security.ssl.require_safe_negotiation enabled. That's not awesome.

Comment 5

[sjw]

It also doesn't follow our recommendation [1] and doesn't support forward secrecy and still supports RC4.

[1] https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility

Comment 6

[April King [:April]]

We wouldn't expect it to support Modern, since it's a general purpose server used for a variety of clients.  It's a site that would use Intermediate.  And I see it supporting forward secrecy just fine with ECDHE:

prio  ciphersuite                  protocols              pfs                 curves
1     ECDHE-RSA-AES256-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits  prime256v1,secp384r1,secp521r1
2     AES256-SHA                   TLSv1,TLSv1.1,TLSv1.2  None                None
3     ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2                ECDH,P-256,256bits  prime256v1,secp384r1,secp521r1
4     ECDHE-RSA-AES128-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits  prime256v1,secp384r1,secp521r1
5     AES128-SHA                   TLSv1,TLSv1.1,TLSv1.2  None                None
6     ECDHE-RSA-RC4-SHA            TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits  prime256v1,secp384r1,secp521r1
7     RC4-SHA                      TLSv1,TLSv1.1,TLSv1.2  None                None
8     ECDHE-RSA-DES-CBC3-SHA       TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits  prime256v1,secp384r1,secp521r1
9     DES-CBC3-SHA                 TLSv1,TLSv1.1,TLSv1.2  None                None

It does support RC4 (which should be turned off), but it doesn't prioritize it.  In any case, it's a far deal better than no TLS at all.

Comment 7

[Ed Morley [:emorley]]

It seems there are a few parts to this:
1) Support HTTPS [DONE]
2) Encourage use of HTTPS:
 (a) Get the link creation API to generate https URLs by default
 (b) Serve an HSTS header, and ideally have it preloaded

Liz, would you know who best to contact on the Bitly Enterprise team to see if they can help re #2?

Many thanks!

Comment 8

[Liz Hull]

Hey Ed! Sorry I missed this one. Our bitly contact Lea will probably be our best bet to getting in touch with the right people. Want to get an email thread started that I can loop her into? 

Thanks!

Comment 9

[April King [:April]]

Looking at this, it seems like https is still working great and HSTS is enabled. Unfortunately, the site doesn't redirect http --> https first, so HSTS won't trigger if a user has visited over HTTP.

Liz, could you please contact somebody at bit.ly to fix this for us? It shouldn't be too tricky.

As an example, currently it goes:
http://mzl.la/FamilyDay17 -> https://wiki.mozilla.org/Friends_Family_Day_2017

And instead it should go:
http://mzl.la/FamilyDay17 -> https://mzl.la/FamilyDay17 -> https://wiki.mozilla.org/Friends_Family_Day_2017

Once that first redirection is done, HSTS should make sure that the client won't need it in the future and so it shouldn't future impact performance.

The nice thing is that the Observatory already has a test for this:
https://observatory.mozilla.org/analyze.html?host=mzl.la

So it should be easy for them to test once they have made the change.

Thank you so much!

Comment 10

[rugk]

Any news here?

Comment 11

[Liz Hull]

Ah, thanks for the ping! I totally forgot about this. Let me follow up with our rep right now - when I reached out about this a while back they ended up passing me on to a new rep as they'd shifted roles and that's where that died.

Comment 12

[Liz Hull]

Follow up! Heard back from bit.ly and here's what our rep said: 

"We recently moved all of our links to Https for a additional layer of security. I spoke to my team and they jumped into your account and didn't see any known bugs within your account. I would be happy to jump on a call and see what exactly the issue is in real time."

Has the issue resolved or do we need to get some time with them? 

Thanks!

Comment 13

[Ed Morley [:emorley]]

The steps in comment 9 still reproduce - could you ask their sales rep to have one of their engineers take a look at it? (HTTPS works but isn't set up in-line with best practices for allowing HSTS)

Comment 14

[Liz Hull]

Sure - who should I loop into this email thread? Would love to have our rep loop in someone from his engineering team too as we're both not very knowledgeable middle-men on this topic at the moment!

Comment 15

[Ed Morley [:emorley]]

I'd CC April (april@moco). Many thanks for your help with this :-)

Comment 16

[Kohei Yoshino]

There's also a contact address mentioned at https://support.bitly.com/hc/en-us/articles/231139148-How-do-I-enable-https-for-my-Branded-Short-Domain-bsd-

Comment 17

[Gene Wood [:gene]]

This appears resolved as bit.ly now redirects to https and serves an HSTS header

$ curl -i http://mzl.la/1LG5eZp
HTTP/1.1 302 Found
Server: nginx
Date: Mon, 01 Nov 2021 21:26:19 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 109
Location: https://mzl.la/1LG5eZp
Strict-Transport-Security: max-age=1209600
Via: 1.1 google

<html>
<head><title>Bitly</title></head>
<body><a href="https://mzl.la/1LG5eZp">moved here</a></body>

Comment 18

[sjw]

This violates the spec:

An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.

https://datatracker.ietf.org/doc/html/rfc6797#section-7.2

Bitly should redirect to HTTPS and only include the HSTS header in the HTTPS response.

Comment 19

[:Atoll]

(I checked and bitly also sends the header over HTTPS, so while the spec violation is suboptimal, the outcome is still effective.)

Comment 20

[Darkspirit]

(In reply to sjw from comment #18)

This violates the spec:

That doesn't matter.

What would be useful is preloading:
Could you ask bitly for a config option to set max-age=63072000; includeSubDomains; preload for https://hstspreload.org/?

Comment 21

[Gene Wood [:gene]]

I've emailed Bitly support

Hi, I work in the Security department at Mozilla. Mozilla is a Bitly customer. We noticed that Bitly hasn't implemented the HSTS standard on their webservers correctly. In the HSTS spec it states

An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.

https://datatracker.ietf.org/doc/html/rfc6797#section-7.2
This is to ensure that the STS header isn't sent over a channel that an attacker could modify.
Unfortunately, Bitly's webservers are currently configured to send the STS header over HTTPS and HTTP. You can see this by running a command like

curl -i http://mzl.la/1LG5eZp
The headers of the response from the Bitly servers contains the line
Strict-Transport-Security: max-age=1209600
though it shouldn't.

As Mozilla uses Bitly links to link to resources where it's important to us that an attacker can't modify the content and this rule of the spec exists to ensure no clients could use the insecure STS header passed over HTTP, would it be possible to have this fixed on the Bitly webservers so as to conform to the spec?
-Gene Wood
Security Assurance, Mozilla

Comment 22

[Gene Wood [:gene]]

They never got back to me, I've emailed them again just now

Comment 23

[Gene Wood [:gene]]

I emailed them again on January 22nd and got no response
I emailed again today. I also started a new Zendesk ticket with bitly support in case the original one can't be seen by them for some reason.

Comment 24

[Gene Wood [:gene]]

bit.ly has repsonded

While 7.2 does indicates STS header must not be used on a HTTP response, 8.1 indicates a browser MUST ignore any such field. We therefore include this header on HTTP and HTTPS responses to avoid varying response by protocol, in this case expecting it’s a noop on HTTP responses for well behaved user agents. If a user-agent did respect the STS header on a HTTP response at worst it would make future requests over HTTPS which is desired.

So bitly won't fix this.

I think after 7 years we'll wrap this ticket up