I cannot find authoritative information about how WSS interacts with HTTPS proxies and load balancers.
I have a load balancer that handles the SSL (SSL off-loading), and two web servers that contains my web applications and handle the requests in plain HTTP. Therefore, the customers issue HTTPS requests, but my web servers get HTTP requests, since the load balancer takes care of the SSL certificates handling.
I am developing now an application that will expose WebSockets and SSL is required. But I have no clear idea about what will happen when the load balancer gets a secure HTTPS handshake for WSS.
Will it just relay the request as normal handshake to the web server?
WebSockets use a "Upgrade:WebSocket" HTTP header that is only valid for the first hop (as there is also "Connection:Upgrade", will this be a problem?
Cheers.
loadbalancers can normally deal with websockets - also including ssl offloading shouldn't be an issue - BUT you have to configure the LB to take care about HTTP and not only to take care about balancing the traffic based on Layer 3 infos - therefore, you have to ensure that the LB has to take care about the session state.
i don't know what LB you are using - but e.g. with F5 LBs you just have to assign a http profile to loadbalance websocket based apps.
If you want to do ssl offloading additionally - just assign an ssl client profile to your virtual server.
http://support.f5.com/kb/en-us/solutions/public/14000/700/sol14754.html
I would have thought SSL-terminating LBs handle WebSockets as well, but I had to realize I was mistaken, once I tried. So the answer for F5 LBs, as of January 2013, is: It won't work. The gist of the answer I was given over at serverfault:
As of December of 2012, BIG-IP doesn't support SSL offload of WebSocket traffic.
Related
I'm serving my site through nginx. For securing it, I have added ssl certificate and made it compatible with https protocol.
Now when I do request data from the site through browser while keeping ssl proxying on, whole request body and response body are showing there, so there is some loophole in my configuration and if it's not a loophole, I want it to be like giant company's site - facebook, apple etc. Where these ssl proxy tool can not parse the request and response.
If the client doesnt explicit show itself as a proxy (aka via X-Forwarded headers), is very hard to know for a server if any connection establishes proxied, Of course, out there are sophisticated methods to find these connections, like blacklists with common proxy sites, AI traffic algorithms, etc. but you will need massive amounts of data (that giant companies have) or specialized traffic services like cloudflare.
First of all, title of my question is too long. But this is what I want to know.
I have a server which is configured to handle mutual TLS with a client (this is done by Apache Axis2 code). But, during the deployment I had to put a reverse proxy (a load balancer) in front of my server. Now, the reverse proxy is doing the SSL offloading and it handles the mutual TLS too.
When I surfed internet I learned that in such cases the reverse proxy is sending the client cert in a HTTP header to the backend. Now I am thinking of checking for this header and doing the validation within the axis2 code.
What I want to know is, there a standard / defined header to be used to send the cert to the backend. Is it X-Client-Cert header?
I've just set up CloudFlare on my web app. The free version, since my app isn't generating any revenue right now.
Now all my traffic is routing through CloudFlare's servers, correct? And that connection is "secure" because it's under HTTPS -- Chrome even displays the green padlock.
But CloudFlare is still communicating with my server over HTTP (unsecure connection), are they not?
Doesn't that mean all my client's data is sent in the clear between CloudFlare and my server? And that makes it not really secure at all, despite what Chrome thinks?
No.
The "Flexible" option of the "Crypto / SSL (with SPDY)" setting is not secure. If you read the "Help" text it says:
There is an encrypted connection between your website visitors and CloudFlare, but not from CloudFlare to your server.
You must install an SSL certificate on your own server and then select the "Full SSL (strict)" option to be secure.
You can configure the origin for the CDN (i.e. your servers that provide the original version of the content to be distributed across the CDN) to provide data using HTTPS. With the pro version (which you are not currently using) you can also use the SPDY protocol. HTTPS communication between the CDN and your servers protects that part of the communication path.
Additionally, and optionally, you can use Authenticated Origin Pulls (also available in the free version) to ensure that the CDN and origin (you) are both who you claim to be.
I'm setting up HTTPS Load Balancing (LB) on Google Compute Engine (GCE). Key components are outlined in the Overview Diagram.
After successfully creating a HTTP Backend Service where 1 of 1 (GCE) instance is healthy, I decided to do the same for HTTPS. I'm using the Developer Console UI to do this.
The Healtheck "wizard" provides a drop-down menu for protocol with the option HTTP and HTTPS:
The successful HTTP Heathcheck used the path :8080/admin/healthcheck.
Presumably the HTTPS Healtheck will use the path :443/admin/healthcheck. The problem is my HTTPS Healthchecks are failing. This was expected since when visiting https://[INSTANCE_IP]:443/admin/healthcheck in a browser, it could not connect. So I didn't expect the Healthcheck to mark the instance as healthy.
How can I connect to https://[INSTANCE_IP]:443/admin/healthcheck over TLS, do I merely need to upload a certificate and create a Certificate Resource in the Developer Console (I doubt it)?
I think it's a conceptual problem too.
The URL https://[INSTANCE_IP]:443/admin/healthcheck does exist, I think because the instance doesn't implement TLS, the Healthcheck fails.
What is the relationship between a uploading a certificate (i.e. creating Certificate Resource) and a specific GCE instance accepting HTTPS requests such that HTTPS HealthCheck pass?
After re-reading the documentation, it is stated:
The client SSL session terminates at the load balancer. Sessions
between the load balancer and the instance can either be HTTPS
(recommended) or HTTP. If HTTPS, each instance must have a
certificate.
It is the last sentence that I was trying to achieve because HTTPS Healthchecks use a HTTPS URL to check the 'health' of an individual instance:
https://[INSTANCE_IP]:443/admin/healthcheck
Since this was failing, I incorrectly assumed I needed to implement TLS on each instance for the Healthcheck to succeed. However, I do not require each instance to implement TLS (HTTPS), only the Load Balancer.
The final configuration I used involved creating a new HTTPS Target Proxy, which pointed to the same Backend Service used for the HTTP Target Proxy. In other words: 2 Target Proxies (HTTP and HTTPS), but only one Backend Service).
Since Healthchecks are employed by Backend Services, the only Healthcheck required was the (original) unsecure Healthcheck, i.e.
http://[INSTANCE_IP]:8080/admin/healthcheck
The next sentence is important to:
The Beta release of HTTPS load balancing only supports a single SSL
certificate with a single load balancing service.
If the beta release only supports a single SSL certificate, I assume this certificate belongs to the LB, and therefore, on the beta at least, it's not actually possible to secure individual instances.
We are currently using Apache to handle incoming SSL requests. These are two-way SSL connections. Apache accepts the https connection and pass the request on as http connection to the application server. This works well for us.
We would like to use the same kind of centralized mechanism for outgoing two-way SSL connections. Is there a way do this with Apache or another product? To complicate things the client certificate needed to identify out client can vary depending on the destination.
In short:
- Internal clients connect through http to Apache or another product.
- Apache or another product knows based on a rule (?) that a two-way ssl connection is required and sets this up with the destination.
- Depending on the destination the correct certificate is sent to identify our client.
Regards,
Nidkil
What you're talking about is, or course, an HTTP proxy server. In the first scenario you are using it as a transparent proxy to provide SSL support for connections to a set of web pages. In the second scenario you want to use it to provide connections to secure-only pages on behalf of clients speaking HTTP.
You can do this with the Squid proxy, which is free and open-source, provided that your machine sits between the clients and the Internet. Look for "SSLBump". You do need a certificate which the clients would consider valid for all web pages to be accessed (otherwise they will notice what you are doing, which is basically a man-in-the-middle attack).
However, I would strongly recommend against this - if a site requires SSL, it is likely to do so for a reason. It is almost certainly not OK to have internal clients connecting to an online banking site and have you bumping down their encryption so that you can monitor their traffic or whatever...