Repository navigation
HTTPS no longer works on j.mp - disable the ruleset #5083
Description
Activity
@jehiah What happened to https://j.mp/? Its certificate now only covers bit.ly and www.bit.ly. Is it an intentional change or a bug?
(Also it's vulnerable to the OpenSSL padding oracle vulnerability CVE-2016-2107.)
https://www.ssllabs.com/ssltest/analyze.html?d=j.mp
The ruleset can easily be changed to rewrite j.mp to https://bit.ly/, but this has wider impact, on other people using https://j.mp/.
ETA: I pushed a branch (mnordhoff/https-everywhere@65ab5d2) to rewrite j.mp to bit.ly, if that's the best course of action.
At least one Bitly client domain, thesent.nl, also has a (www.)bit.ly certificate.
https://www.ssllabs.com/ssltest/analyze.html?d=thesent.nl
I checked about 20 other domains from the Bitly vanity ruleset without finding a third.
@J0WI @mnordhoff Yes,
j.mpis owned by Bitly. We've resolved this SSL issue on our side, so we can close this issue now. (sorry for the delay in responding)Some background: At Bitly we are in the middle of migrating our platform to a new datacenter, and due to some capacity constraints needed to temporarily migrate j.mp to an independent system in a 3rd datacenter. We call this system which we keep on standby to serve redirects on links in case of failures in our normal link redirect system "plan-z". It's meant to keep Bitly links working even if we experience total loss of connectivity to our primary datacenter.
By it's nature plan-z is both software and datastore diverse from our normal redirect process to better insulate it from human errors that might affect both systems. Unfortunately this plan-z system hasn't been setup to handle SSL termination for multiple domains until now (which is why it was returning the bit.ly certificate). We've now completed that work so when we need to leverage this backup system, it will handle SSL for all domains just like our normal backend does.
As a side-note: the expected behavior is that a domain will appear to revert back to the
bit.lycertificate when we don't have a better one available. Based on normal domain churn this will happen periodically and i'll be updating the full domain list from #4505 at the end of the month. That's the case forthesent.nlwhere we are no longer able to obtain a LetsEncrypt certificate for that domain.Reacted by J0WI and Matt NordhoffThanks a lot for your statement on this!
HTTPS no longer works on j.mp, so the ruleset should be disabled.
Sample: http://j.mp/12ZHdor