Should domains which only make redirects (aka tiny urls) be encrypted (https)?

Should redirect sites use HTTPS

If the main site uses HTTPS then the redirect site should too.

What attacks are possible if it does not

Passive Attacker

• Can see every item looked at by the user
• May get extra information (which site/chat linked to the page)

Active Attacker

Anything a passive attacker can, and...

• Can MITM the connection and use something like SSLStrip to prevent the connection upgrading to HTTPS, allowing then to watch passwords, credit card numbers, etc.
• Can add a cookie to the reply, allowing them to track a user
• Can redirect the traffic to a phishing site, or a site that installs malware.

How to prevent using HTTP entirely, to stop tools like SSLStrip

• You can serve an HSTS header, so only the first visit (and the first visit once the header expires) will use HTTP, so an attacker cannot intercept the traffic
• If you with to prevent these weaknesses you can add your site to the HSTS Preload List, which will prevent HTTP connections.
• This would need to apply for both sites, as if the main site is HSTS but the redirect then the attacker could redirect to a site they control instead, bypassing HSTS.

Should I use HTTPS

Generally, YES

There are very few occasions when you can get away with not using HTTPS, all of these need to apply:

• You manually sign your data - and always verify the signature

• You do not care about people finding out your software is running on someone's machine

• You do not handle any sensitive information, or information users may want to keep secret
• You won't accidentally get sensitive information sent over your system
  • An example would be ACARS, it's wasn't meant for sensitive information, but credit card numbers have been sent over it without realising the problems caused. [forum, paper]
• You do not care or can detect if someone swaps around the files, using other valid signed ones
• The service does not imply sensitive data (a page about a disease may not be sensitive, but the fact that someone is searching about the disease may be sensitive).

There are very few cases where using just plain HTTP and not HTTPS is a good idea. This is probably not one of them.

Consider this scenario: A user clicks a link to http://exmpl.com/foo, hoping to buy some new foo. A man in the middle intercepts the request, and responds with a phishing copy of https://example.com/items/42 instead of a redirect to the legitimate one. The user, being lazy as users are, doesn't check what url he was redirected to - after all, he knew he clicked the right link. Instead he proceeds to enter his credit card details into the phishing site. He thinks he's shopping for foo on a legitimate site, while in fact he is getting scammed.

Sure, the user made a mistake here. But it's a mistake that would not have mattered had you only used HTTPS.

When the user is privacy-conscious, they might want to minimize the amount of data an eavesdropper can collect about them. When you use HTTPS, then the whole request is encrypted. The eavesdropper only knows which server the user accessed and (approximately) how much data was exchanged.

When exmpl.com doesn't use HTTPS, the eavesdropper knows:

• Subject accessed http://exmpl.com/foo
• Subject received a http-redirected to https://example.com/items/42
• Subject accessed an unknown (but now easy to infer) URL on the domain example.com
• Subject received a long encrypted response

When you use HTTPS, all the attacker knows:

• Subject accessed an unknown URL on the domain exmpl.com
• Subject received a short encrypted response
• Subject accessed an unknown URL on the domain example.com
• Subject received a long encrypted response

The attacker doesn't learn which redirect the user used and so they don't learn that that the user visited items/42. The attacker also can not be sure that these two accesses were related.