7

Wikipedia defines HTTP(S) or S-HTTP as a security layer over HTTP:

Technically, it is not a protocol in and of itself; rather, it is the result of simply layering the Hypertext Transfer Protocol (HTTP) on top of the SSL/TLS protocol, thus adding the security capabilities of SSL/TLS to standard HTTP communications.

Logically, it implies that every feature and aspect of HTTP (e.g. methods and status codes) exists in HTTPS.

Should I expect any caveats or differences when switching an existing HTTP REST interface to HTTPS?

Siva Tumma
  • 1,695
  • 12
  • 23
Adam Matan
  • 128,757
  • 147
  • 397
  • 562

3 Answers3

7

There doesn't seem to be any limitation of what you can do with HTTP but not HTTPS. The only limitations/differences relate to the fact that the connection is encrypted. As Eugene mentioned, this includes the fact that HTTPS cannot be proxy-cached. There are however some caveats:

HTTP inline content inside HTTPS page

If you start using HTTPS for sites where you originally used HTTP, problems might arise with HTTP inline content, e.g. if you use 3rd party HTTP services or cross-domain content:

  • scripts: google maps API
  • iframes: other webs, facebook, google ads, ...
  • images, static google maps, ...

In that case, many browsers will disable the "insecure" HTTP content inside HTTPS page! For the user, it is very hard to switch this off (especially in Firefox).

The only reliable way around that is to use protocol-relative URLs. So, instead of:

<script src="http://maps.googleapis.com/maps/api/js?v=3.exp&sensor=false"></script>

which would break on HTTPS page, you will just use

<script src="//maps.googleapis.com/maps/api/js?v=3.exp&sensor=false"></script>

which will work as HTTP on HTTP page and as HTTPS on HTTPS page. This fixes the problem.

The downside of course is that it is useless encryption of large amount of network traffic, that is not vulnerable and wouldn't normally have to be encrypted. This is the cost of the paranoid browser approach to security (like year ago, there was no warning from FF in this situation, and I was completely happy. World changes ...)

If you don't have signed SSL certificate for your domain

Another caveat of course is that if you don't have SSL certificate for your domain which is signed by trusted CA authority, then if your users will use HTTPS, they will have to pass a terrible scary 4-5 step procedure to accept the certificate. It is almost impossible and unprofessional to expose an average user (unaware of the problematics) to this. You will have to buy certificate in this case. Many times you end up using HTTP instead of HTTPS because of this. So if you cannot afford to buy the certificate, the browser paranoia forces you many times to use insecure HTTP protocol instead of HTTPS. Again, 6-7 years ago, it wasn't the case.

Mixing HTTP and HTTPS - cookie and authorization problems

If you use both HTTP and HTTPS within the same session, you might run into problems because sometimes they will be treated as separate sites (even if the rest of the URL is the same). This might be the case of cookies - in some cases they will not be shared between HTTP and HTTPS. Also, the HTTP authentication - RFC2617 will not be shared between HTTP and HTTPS. However, this type of authentication is now very rare on the Web, possibly due to lack of customization of the login form.

So, if you start using HTTPS, easiest way is then to use HTTPS only.

After several years of running HTTP over HTTPS, I am not aware of any other caveats.

Community
  • 1
  • 1
Tomas
  • 57,621
  • 49
  • 238
  • 373
1

Performance Considerations

HTTPS Client/Broswer Caching

Top 7 Myths about HTTPS - Note commentary on HTTPS caching that is handled differently in browsers. It's from 2011 though, the browsers might have changed.

Will web browsers cache content over https

More on why there is no HTTPS proxy caching

Can a proxy server cache SSL GETs? If not, would response body encryption suffice?

UPGRADE command in Websockets via HTTPS

While the WebSocket protocol itself is unaware of proxy servers and firewalls, it features an HTTP-compatible handshake so that HTTP servers can share their default HTTP and HTTPS ports (80 and 443) with a WebSocket gateway or server. The WebSocket protocol defines a ws:// and wss:// prefix to indicate a WebSocket and a WebSocket Secure connection, respectively. Both schemes use an HTTP upgrade mechanism to upgrade to the WebSocket protocol.

http://en.wikipedia.org/wiki/WebSocket

Community
  • 1
  • 1
Dannie
  • 2,430
  • 14
  • 16
-1

As a coder of REST, I do not see any possible caveats when you switch HTTP REST to HTTPS. In times if you find some, you would definitely have them in normal HTTP REST too.

Siva Tumma
  • 1,695
  • 12
  • 23