I have web server IIS, where I have direct access to page like (page.com), so thats the reason why I have allowed HTTP (port 80) and then I am using HTTPS (port 443).
When user enters the page on port 80 (page.com), he will be redirected to HTTPS (443). So my web server uses HSTS with long max-age parameter (defense against ssl strip).
Is my page secure with HSTS header this way? If not, what should I do?
Thanks a lot!
As always, the question is secure against what? Secure against ssl strip after the first response with HSTS (and before it expires)? Yes. Secure against ssl strip on the very first request (or the first after HSTS expired)? No. Secure against a range of different attacks? Not necessarily (dns hijack on the first request, corporate ssl inspection, rogue root cert in clients, malware... the list is endless).
Could you make it more secure? Yes, by disabling plain http altogether. Would that make sense in your scenario? Only you can tell.
Related
I have a web application running on AWS EC2 using a load balancer which only listens for HTTPS requests on port 443 along with a security group which only allows for traffic on port 443 so my application cannot be reached via HTTP (as far as I am aware).
The application has recently been pen tested which resulted in the recommendation to implement HSTS. From what I can see one of the requirements for implementing HSTS is to redirect ALL HTTP links to HTTPS with a 301 Permanent Redirect. Upon trying to do this through another listener on the load balancer redirecting traffic from port 80 to port 443 I get a warning that the security group attached "does not allow traffic on this listener port."
My question is should I consider enabling HTTP traffic so that I can implement the permanent redirect and then implement HSTS or am I better off leaving things the way they are? I'm inclined to think that because my load balancer does not allow HTTP traffic that I'm better off leaving my current set up as is but not 100% sure. Can anyone explain which is the safer option and why? Thanks in advance.
It totally depends on whether you want to allow and redirect HTTP traffic to HTTPS. For example if it's a user facing application then generally HTTP traffic allowed at gateway/load balancer and then redirected to HTTPS as end user shouldn't get any error on accessing on HTTP. Then in this case HSTS header plays important role.
But it's not end-user facing application and you know consuming entity will always access using HTTPS then don't allow HTTP traffic. So here you won't need to have HSTS header set.
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.
If a client is requesting a domain that does not have a valid CA signed certificate and the server not intend on supporting HTTPS but does support HTTP for this domain, what is the best way to handle this in the web server. Note, the server does handle requests for SSL (HTTPS) on other domains so it is listening on 443.
Example where this would apply is for multi sub-domains where the sub-domains are dynamically created and thus making it extremely difficult to register CA signed certificates.
I've seen people try to respond with HTTP error codes but these seem moot as the client (browser) will first verify the certificate and will present the hard warning to the user before processing any HTTP. Therefore the client will only see the error code if they "proceed" past the cert warning.
Is there a canonical way of handling this scenario?
There is no canonical way for this scenario. Clients don't automatically downgrade to HTTP if HTTPS is broken and it would be a very bad idea to change clients in this regard - all what an attacker would need to do to attack HTTPS would be to infer with the HTTPS traffic to make a client downgrade to unprotected HTTP traffic.
Thus, you need to make sure that the client either does not try to attempt to access URL's which do not work properly (i.e. don't publish such URL's) or to make sure that you have a working certificate for these subdomains, i.e. adapt the processes for creation of subdomains so that they not only have an IP address but also a valid certificate (maybe use wildcard certificates).
Considering these websites don't have to work with SSL, the webserver should close all SSL connections for them in a proper way.
There is no canonical way for this, but RFC 5246 implicitly suggests to interrupt the handshake on the server side by using the user_cancel + close_notify alerts. How to achieve this is another question, it will be a configuration of the default SSL virtual host.
user_canceled
This handshake is being canceled for some reason unrelated to a
protocol failure. If the user cancels an operation after the
handshake is complete, just closing the connection by sending a
close_notify is more appropriate. This alert should be followed
by a close_notify. This message is generally a warning.
If you are dealing with subdomains, you probably can use a wildcard certificate for all of your subdomains.
Adding the CA certificate to your client will remove the warning (that's what companies do, no worry).
When hosting with Apache, for example, you can use VirtualDocumentRoot to add domains without editing your configuration. Have a look at the solution provided here : Virtual Hosting in SSL with VirtualDocumentRoot
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.