I was just wondering this small little question. I know it is irreverent to coding, but I just had to know quickly.
If you type in http:// for a https:// will it still take you to the correct place?
That is mostly dependent on the server configuration. The server has to accept the initial HTTP request and be configured to redirect the client to an appropriate HTTPS url.
That being said, there are some Internet standards related to automating HTTP-to-HTTPS upgrades. HTTP Strict Transport Security and Upgrade Insecure Requests allow an HTTP/S server to tell clients that it wants them to automatically use HTTPS for all subsequent requests. If a client visits an HSTS/UIR-enabled server, it will receive a normal HTTP response with additional HSTS/UIR-related headers. If the client supports HSTS/UIR, it will then know to automatically send all subsequent HTTP requests to that same server using HTTPS, and in the case of UIR also treat any received HTTP URLs as if they were HTTPS URLs.
Related
Is there a posibillity to check if a remote server supports https?
Currently im requesting https, if it doesnt work retry http and then display an error if this still does not work.
Is there a feature embedded in HTTP which indicates if https is supported?
By this I dont mean redirect etc. because these must be implemented on the server and arent always.
Silently falling back to HTTP sounds dangerous. An attacker (i.e. man-in-the-middle) might be able to force you to use the insecure channel by blocking your requests to HTTPS. Thus, I would not recommend this approach in general.
In general, you should let your users decide which protocol to use. If they specify https, you should not silently downgrade but throw an error. If they specify http however, it might be possible to also try https first and silently fall back to http if that fails (since they requested http in the first place).
An a general answer to your request: you can only try https to check if the server supports https. There is an HTTP(s) extension called HTTP Strict Transport Security (HSTS) which allows servers to indicate that all requests to them should always be performed via secure channels only. If you receive such a header in a response for an HTTPS request, you can force https in the future for the host. Note though that you have to ignore such headers receive over insecure HTTP.
In general, you can't trust any information you received over plaintext HTTP to give you any indication about security options (such as support for TLS) of the server since this information could be arbitrarily spoofed by man-in-the-middle attackers. In fact, preventing such undetectable changes is one of the main reasons to use TLS / HTTPS in the first place.
I don't quite get the difference between UseHsts and UseHttpsRedirection in the configure section of the startup file in .net core. Could anyone explain?
According to the documentation you should use both together:
We recommend all production ASP.NET Core web apps call:
The HTTPS Redirection Middleware (UseHttpsRedirection) to redirect all HTTP requests to HTTPS.
UseHsts, HTTP Strict Transport Security Protocol (HSTS).
ASP.NET Core Enforce HTTPS
The .UseHttpsRedirection() will issue HTTP response codes redirecting from http to https. The .UseHsts() will add the HSTS response header which the client is supposed to obey.
UseHsts adds the Strict-Transport-Security header to the response, which informs the browser that the application must only be accessed with HTTPS.
After this declaration, compliant browsers should automatically convert any http request of the application into an HTTPS request.
UseHttpsRedirection causes an automatic redirection to HTTPS URL when an HTTP URL is received, in a way that forces a secure connection.
Once the first HTTPS secure connection is established, the strict-security header prevents future redirections that might be used to perform man-in-the-middle attacks.
I understand that HTTTPS is secured and it requires SSL certificate issued by CA authority to make the application secure. But what I do not understand is that its in-depth difference with HTTP.
My question, as a user, if I make a request to an application with HTTP or if I make same request to HTTPS what is the actual difference? The traffic remains same to both. Is there any traffic filtering happening if I use HTTPS?
Thanks
HTTPS, as an application protocol is just HTTP over TLS, so there are very few differences, the s in the URL and some consequences for proxy, that is all.
Now you are speaking about the traffic and the filtering. Here you have a big difference because using TLS adds confidentiality and integrity: passive listeners will see nothing about the HTTP data exchanged, including headers. The only thing visible will be the hostname (taken from the https:// URL) as this is needed at the TLS level before HTTP even happens, through a mechanism called SNI (Server Name Indication) that is now used everywhere to be able to install multiple services using TLS under different names but with a single IP address.
For HTTP, it is possible to upgrade all requests to HTTPS with a 301 response.
For websocket, however, it doesn't seem to be that easy. If I redirect the ws://127.0.0.1 request to wss:/127.0.0.1, I get an "error: undefined" in the browser using the test on websocket.org (and yes, certificate is trusted and works for wss if used directly). The initial request is made, and the redirect sent out. However, there is no second request on the TLS port.
The specification only covers redirects briefly.
Is upgrading ws to wss possible?
Do I need to send WebSocket specific headers even with the redirect response? (Currently, I don't – and the specification lists redirecting before completing the handshake)
Any other thing that I miss?
For HTTP, it is possible to upgrade all requests to HTTPS with a 301 response.
(Nitpicking) That's not really an upgrade of a request but instead a redirect which results in a different request.
Is upgrading ws to wss possible?
According to the websocket standard (RFC 6455):
If the status code received from the server is not 101, the
client handles the response per HTTP [RFC2616] procedures. In
particular, the client might perform authentication if it
receives a 401 status code; the server might redirect the client
using a 3xx status code (but clients are not required to follow
them), etc.
So yes, it might be supported be some clients but not by others. For example in Firefox the relevant property network.websocket.auto-follow-http-redirects defaults to false, i.e. it does not follow redirects by default.
Do I need to send WebSocket specific headers even with the redirect response?
These are only relevant for the upgrading of the request to websocket not for redirects. This means the headers should only be sent in the upgrade response (status code 101).
It depends upon whether the webSocket client implementation processes 3xx status codes or not. The webSocket specification does not require a client implementation to do so. Here's a quote from the spec:
If the status code received from the server is not 101, the
client handles the response per HTTP [RFC2616] procedures. In
particular, the client might perform authentication if it
receives a 401 status code; the server might redirect the client
using a 3xx status code (but clients are not required to follow
them), etc. Otherwise, proceed as follows.
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?
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.
Performance Considerations
HTTP vs HTTPS performance
HTTPS vs HTTP speed comparison
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
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.