Closed Bug 1193634 Opened 9 years ago Closed 3 years ago

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

Categories

(Marketing :: Social Media, task)

Product:
Marketing
Component:
Social Media
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: sjw+bugzilla, Unassigned)

References

(
URL
)

Details

+++ 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.
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/1546]
I think Mozilla IT has nothing to do here, because the mzl.la server is owned and managed by bitly.
Assignee: server-ops-webops → nobody
Component: WebOps: Other → Social Media
Product: Infrastructure & Operations → Marketing
QA Contact: smani
Version: other → unspecified
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/1546]
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/1551]
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/1551]
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!
https://mzl.la/ is using Let's Encrypt. That's awesome!
I get SSL_ERROR_UNSAFE_NEGOTIATION with security.ssl.require_safe_negotiation enabled. That's not awesome.
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
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.
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!
Flags: needinfo?(ehull)
Summary: Provide TLS on https://mzl.la/ → Provide TLS on https://mzl.la/ and set up redirect and HSTS header
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!
Flags: needinfo?(ehull)
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!
Flags: needinfo?(ehull)
Any news here?
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.
Flags: needinfo?(ehull)
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!
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)
Flags: needinfo?(ehull)
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!
Flags: needinfo?(ehull)
I'd CC April (april@moco). Many thanks for your help with this :-)
Blocks: hsts-preload-everything
Flags: needinfo?(ehull)

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>
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(ehull)
Resolution: --- → FIXED

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.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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

(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/?

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

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

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.

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

Status: REOPENED → RESOLVED
Closed: 3 years ago → 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.