I wish to setup an HTTPS proxy and have HTTP clients send requests securely to the proxy. For example, a browser can initiate a HTTP GET request which should be an encrypted request to the proxy and the proxy then removes the encryption and then passes the request to the end-site. Squid proxy can be set up to work like this (info here).
I have set up such a HTTPS enabled proxy. But I am unable to write my own HTTP clients to work with it. The same link above mentions that chrome is the only browser that supports such a proxy. I tested Chrome and it was able to work with such an HTTPS proxy.
I wish to gain an understanding of how such a proxy works so that I can write my own HTTP clients.
As I understand it, it's a connection to regular HTTP proxy BUT this connection is made over TLS. The client indeed needs to support this scheme explicitly and existing clients as-is can't be tuned up (without extra coding).
Related
There are several questions that relate to this, but they're either very specific, inconclusive or outdated:
Is it possible to make a cross domain request from https to http in IE?
Can IE8 post cross-domain requests from HTTP to HTTPS?
Cross domain HTTP requests
Cross domain request from HTTP to HTTPS aborts immediately
And a few others.
As of now, is it at all possible to make any (GET, PUT, POST...) HTTP request, within JavaScript, to a server that does not have a valid SSL certificate, in a page served from a HTTPS server? Without, of course, asking the user to trust a self-signed cert or disable protections.
I've tried fetch and XMLHttpRequest requests, but they either get blocked by the browser because of CORS or generic "TypeError: NetworkError".
My specific predicament is that I have a home server accessible through a dynamic DNS provider (free tier). I cannot easily obtain an SSL certificate because my ISP blocks HTTP requests to port 80, which makes Let's Encrypt HTTP-01 challenge basically impossible.
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.
Ant-Media-Server is running on an IPAdress without any domains. We just set up this server to be used for streaming in order to use it from different domains pointing to different servers.
Since all of our domains use ssl, we face the typical connection problem:
mixed Content: The page at 'https://SOMEDOMAIN.com/QUERY' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://1.2.3.4:56'. This request has been blocked; this endpoint must be available over WSS.
Ant-Media already offers tutorials on how to install a Let's Encrypt SSL Certificate but sadly it is not available for pure IP-Addresses.
Apart from the Ant-Media Service, the server doesn't has any NGINX, NodeJS, Apache or other http Servers installed - the plan was just to use it for streaming by calling the IP-Address.
Do you have any ideas on how to solve that problem?
Unfortunately, this is not possible.
The goal of having a SSL is ensure you are requesting the right domain name besides encrypting the content between your users and your server.
Here are some alternatives:
create an endpoint in your own app that proxies data to your server.
Instead of playing the IP address, you can play:
/your-proxy-url?stream=http://yourIp.com:port/....
Note that using a proxy will make all the traffic pass through your web app.
As a reference, if you are using PHP on your website, you can have some ideas from here: https://gist.github.com/iovar/9091078
Create a reverse-proxy in front of your web app that redirects the traffic to your IP address.
Both solutions does not change your Ant Media Server, just adds a new resource between your users and your streaming server - adding the SSL on it.
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.
I have configured JBoss with HTTPS connector only. Now I have problem, that in case I'm using HTTP request to HTTPS connector, it returns page with one ASCII character, instead of some error page, for example 505 or something else what can user inform, about invalid request.
There is no used Apache nor any other web server, where some rules for URL rewriting could apply. Also often used change in web.xml with <transport-guarantee>CONFIDENTIAL</transport-guarantee> tag do not solve this problem, as there must be HTTP request, which is then redirected to HTTPS based on "redirectPort" param in connector configuration and in this case there is not plan to use any other port and it is not possible to combine HTTP and HTTPS listener together on one port.
Is there some way how to configure SSL listener, that way, that it refuse HTTP request, or automatically change to HTTPS?
JBoss 5.1.0
Your browser uses HTTP to talk to server, but on the server side is the security layer (around the HTTP) and it wants to do a SSL/TLS handshake. So the communication fails because client doesn't know about the security on the other side.
The client (browser) receives error message (binary data) from server. The client doesn't know what to do with them, so it presents them to a user as a web page content.
RFC-5246 states:
Error handling in the TLS Handshake protocol is very simple. When an
error is detected, the detecting party sends a message to the other
party. Upon transmission or receipt of a fatal alert message, both
parties immediately close the connection.
Undertow - a new web server in WildFly - is able to do HTTP Upgrade. But I'm not sure if the upgrade to SSL/TLS is already supported. Nevertheless, the problem with this scenario could be on the browser side.