I have an apache proxy in our DMZ which then proxies on port 80 to and internal server. It uses port 80 so our firewall between the DMZ and internal network can inspect the request. So, it's like this;
browser -> 443 -> proxy -> 80 -> firewall -> internal server
This all works well but for one thing. If the user calls "https:/site/" this will end up calling http:/site on the internal server. This works fine if the page is there and get 200 and return data. However, if the app on the server tries to redirect the client to a /site/login page for example. This redirect seem to be sent back as http:/site/login, presumably because the connection from the proxy was http port 80. This then results in the client getting this error;
Bad Request
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
How can I make this work better? Either, 1/ make the redirect match the http/https from the original request, or 2/ if I can't do that, force it to always be an https in the redirect sent back?
Thanks
Related
I am going to launch my local Vue application with ngrok.
I used this command.
ngrok http 8080
It says online.
But when I visit this site, it shows error.
This is the output from the ngrok.
I think the problem is HTTPS. My local version is HTTPS.
Here is the screenshot.
How can I solve this problem?
ngrok assumes that the server it is forwarding to is listening for unencrypted HTTP traffic, but if your server is listening for encrypted HTTPS traffic you can specify a URL with an https:// scheme to request that ngrok speak HTTPS to your local server.
Forward to an https server by specifying the https:// scheme
ngrok http https://localhost:8080
As a special case, ngrok assumes that if you forward to port 443 on any host that it should send HTTPS traffic and will act as if you specified an https:// URL.
Forward to the default https port on localhost
ngrok http 443
ngrok assumes that your local network is private and it does not do any validation of the TLS certificate presented by your local server.
If need be, explicitly direct to https locally.
ngrok http https://localhost:8080 -host-header="localhost:8080"
Try ngrok without http
And use node js code to mark -8080 port as your server address
const ngrok = require('ngrok');
(async function() {
const url = await ngrok.connect(8080);
})();
When you'll run this this will create a url use that url to access your server
The main problem is that you don't have a valid ssl certificate on localhost.
You need to expose the normal http not the https. I think it is going to work eg:
ngrok http http://localhost:8080
And in the vue server try to avoid the ssl or https encryption.
I'm listening on to port 80 and 443 using the TCPListener in my .net application. This is windows service and not a web application therefore not hosted in the IIS as well.
I know there are many ways to redirect the request from http to https using the URL Rewrite in the IIS.
BUT, it there any clean way of redirecting all the incoming requests on port 80 to port 443. Basically I want to enforce a secure connection with the server.
Any help in this regard will be great.
Thanks
I have an Apache server in front of a Websocket Tomcat server, and I would like to restrict access to secure websockets only (wss://).
How can I achieve that in Apache configuration ?
One thing that I do not understand is that even if I block port 80 (not 443) on AWS, it is still possible for me to connect to my unsecured ws via Simple WebSocket Client, whereas a telnet myHost 80 is logically failing...
Actually, configuring Apache with SSL is enough : it will redirect all HTTP traffic to HTTPS.
I did not figure out that quickly, but I can only connect with WS protocol only after I have been redirected by the browser with a simple HTTP request to HTTPS. And then, when I try to connect with WS, looking at Chrome Developer tools, I can see in request headers that the final endpoint is WSS.
So, in Simple WebSocket Client, I am actually silently redirected to WSS endpoint when trying to connect with insecure WS. As I said previously, this silent redirection is enabled only after a HTTP to HTTPS redirection on a simple call in the browser. You can check it by closing your browser and trying to reconnect in WS via Simple WebSocket Client : you will get a 403 HTTP error.
I have a web application running on Apache/Tomcat on a cloud with Linux (Digital Ocean). It had a domain name - example.com. I've encrypted both example.com and www.example.com using Let's Encrypt and now requests to https://example.com and to https://www.example.com work.
Then I wanted to redirect HTTP requests to HTTPS. But noticed that for some reason requests to http://example.com and to http://www.example.com do not work, and I'm not getting any response from my server. I tried to play with Apache configuration files of VirtualHost, but nothing worked for me so far.
Using tcpdump I see that I am receiving requests on port 80 on the server, but nothing happens except that.
What might be the reason for requests to HTTPS to work while requests to HTTP not to work?
Thanks.
Well, if someone else encounters this behavior - the reason for it was the firewall - port 443 (used by HTTPS) was open but port 80 (used for HTTP) was simply closed. Opening it solved it.
First of all I want to make clear that i am not talking about accessing content which is on origin servers that deliver using https which can be done using the module mod_proxy_connect.
What I want is a secured connection between the client and the proxy, also when the origin that is requested actually is served by an unsecured standard http server.
I am using apache 2.2 and also would like to make this possible with apache if that works.
I sniffed some requests using wireshark and noted the following:
A usual http of the url http://example.com/file looksl ike this:
on a connection to the origin server:
GET /file HTTP 1.1
Host: example.com
Note that the host information is stripped from the actual request and the host header is supplied instead (which can be handled server side in named virtual hosts).
When the request goes through a proxy server it looks slightly different:
on a connection to the proxy server:
GET http://example.com/file HTTP 1.1
Host: example.com
Note that the request line now actually contains the full url including protocol and hostname.
The host header is probably redundant, bus if I read the RFC correctly it is required by HTTP 1.1.
So I think about setting up an apache webserver listening on port 443, enable a virtualhost with ssl engine and certificates up and do not bind it to any hostname.
I think that should get apache to talk ssl, but however the certificates common name will not match the host specfied in the connect line to the proxys server ip adress.
Is what I want to to even possible with current standards and if so how can I do it?
Yes of course, that's what HTTPS proxy is.
Client connects to proxy over SSL, sends commands to proxy in text.
It is also possible to use HTTP CONNECT to establish HTTPS connection "inside" the SSL connection to HTTPS proxy, though not all clients support this:
HTTPS connection over HTTPS proxy
client proxy server
ssl \-------/ ssl
connect---------200 OK
ssl \---------------------------/ ssl
data-------------------------------data
/---------------------------\
/-------\
HTTP connection over HTTPS proxy
client proxy server
ssl \-------/ ssl
GET http://server/ ->
GET /
Host: server ->
<---------OK, data
<--------------OK, data
/-------\