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.
Related
I have setup a nginx proxy to pass https url to internal http neo4j web. I can reach the neo4j login page without any issue, but I am forced to use the neo4j+s/bolt+s interface.
Just wondering how I can configure nginx to remove any ssl related info via proxypass module, in order to login in neo4j with ws, no wss?
Thanks,
Chance
I managed to get rid of wss by adding another nginx proxy to set the https url as upstream server in location.proxy_pass. It won't show wss/neo4j+s/bolt+s any more once you visit the web by the http url. Hopefully it will help for anyone has the similar issue as me.
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.
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 need to use http health checks on a Elastic Beanstalk application, with proxy protocol turned on. That is currently not possible, and the health check fails with a an error --> *58 broken header while reading PROXY protocol
I figured I have two options
Perform the health check on another port, and setup nginx to listen to http requests on that port and proxy to my app.
If it is possible to catch the broken header errors, or detect regular http requests in the proxy_protocol server block, then redirect those requests to a port that listens to http.
I would prefer the latter(#2), if possible. So is there any way to do this?
Ideally, I would prefer not to have to do any of this. A feature request to fix this has been submitted to AWS, but it has no ETA.
The proxy protocol specification says:
The receiver MUST be configured to only receive the protocol described in this
specification and MUST not try to guess whether the protocol header is present
or not. This means that the protocol explicitly prevents port sharing between
public and private access. Otherwise it would open a major security breach by
allowing untrusted parties to spoof their connection addresses.
I think this means that option 2 is a sufficiently bad idea that it's not even supported by conforming implementations of the proxy protocol.
Option 1, on the other hand, seems pretty reasonable. You can set up a security group so that only legitimate health checks can come in on the port without proxy protocol enabled.
Another couple of options spring to mind too:
Simply point your health checks at the thing that's adding the header (i.e. ELB?), rather than directly at your Nginx instance. Not sure if this is possible with Elastic Beanstalk, it's not a service I use.
Use something else to add the proxy protocol header before forwarding the health-check traffic on to your Nginx, which would avoid having to duplicate your Nginx config. For instance a HAProxy running on the same machine as your Nginx could do this. Again, use security groups to ensure that only legitimate traffic gets through.
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.