SeanTech-info
asked on
Only have one IP addressees need a way to have 2 HTTPS services
I only have one public IP address witch right now if you type it in it goes to my exchange server but that is just using port forwarding to my exchange ip address BUT what I need is something like this
https://exchange.example.com > PFsense goes to my exchange server
then something like
https://owncloud.example.com > PFsense to owncloud server
what I need is a application that routes via incoming host-name now this can be done on the pfsense side or something else if there is a better option.
Thank you!
*edit like this*
> Public IP - Domain Name - Internal IP****
>
> 1.1.1.2 - www.domain1.com -> 192.168.1.2****
>
> 1.1.1.2 - www.domain2.com -> 192.168.1.3****
>
> 1.1.1.2 - www.domain3.com -> 192.168.1.4****
>
> 1.1.1.2 - www.domain4.com -> 192.168.1.5****
https://exchange.example.com > PFsense goes to my exchange server
then something like
https://owncloud.example.com > PFsense to owncloud server
what I need is a application that routes via incoming host-name now this can be done on the pfsense side or something else if there is a better option.
Thank you!
*edit like this*
> Public IP - Domain Name - Internal IP****
>
> 1.1.1.2 - www.domain1.com -> 192.168.1.2****
>
> 1.1.1.2 - www.domain2.com -> 192.168.1.3****
>
> 1.1.1.2 - www.domain3.com -> 192.168.1.4****
>
> 1.1.1.2 - www.domain4.com -> 192.168.1.5****
It's unfortunately not quite that simple. The reason you're even facing this problem is because the default way that SSL/HTTPS works is that the HTTP headers (where the destination hostname is) become part of the encrypted message.
So as the message bounces from the original computer to the destination computer, the hostname itself is hidden inside that encrypted mess. The message finally makes its way to the destination server. The destination server looks at the intended IP address and uses it to look up which configuration / private key to use to decrypt the message. Once it's decrypted, then the server can finally see the headers and know what the hostname is.
So the DEFAULT way everything works won't really support what you're trying to do. However, there are two potential non-default ways of achieving this.
1. If you're using Apache and you have a wildcard SSL certificate that applies to both domains, then you could use NameBasedSSLVHosts as described in its documentation here:
https://wiki.apache.org/httpd/NameBasedSSLVHosts
2. You can set up a Squid proxy server on your pfSense server and configure it to act like a man-in-the-middle. It would intercept SSL traffic and decrypt it right then and there, before it got to the final server. At that point, you could build rules to reroute traffic to whatever server you wanted it to go to. The destination server would end up receiving the decrypted, regular HTTP request instead of HTTPS (unless you re-encrypted it).
There are a whole host of problems with #2, mostly about security and load. For example, instead of TWO robust servers handling their own HTTPS connections, now you're having ONE less-robust server / firewall trying to decrypt ALL the HTTPS traffic (and possibly re-encrypt it with different public keys), which adds a significant amount of load to your box.
If you choose NOT to re-encrypt the message as it goes between the firewall and the internal server, then there's a possibility of data exposure during that short internal trip (and that's the most likely place it will happen, too). It also means that the public-facing pfSense box would need to have the private key, so if the firewall ever got hacked, the malicious users would be much closer to being able to obtain that private key.
You'd have to weigh the risks and benefits, but it's usually FAR easier and FAR less-risky in the long run to simply pony up for a second IP.
So as the message bounces from the original computer to the destination computer, the hostname itself is hidden inside that encrypted mess. The message finally makes its way to the destination server. The destination server looks at the intended IP address and uses it to look up which configuration / private key to use to decrypt the message. Once it's decrypted, then the server can finally see the headers and know what the hostname is.
So the DEFAULT way everything works won't really support what you're trying to do. However, there are two potential non-default ways of achieving this.
1. If you're using Apache and you have a wildcard SSL certificate that applies to both domains, then you could use NameBasedSSLVHosts as described in its documentation here:
https://wiki.apache.org/httpd/NameBasedSSLVHosts
2. You can set up a Squid proxy server on your pfSense server and configure it to act like a man-in-the-middle. It would intercept SSL traffic and decrypt it right then and there, before it got to the final server. At that point, you could build rules to reroute traffic to whatever server you wanted it to go to. The destination server would end up receiving the decrypted, regular HTTP request instead of HTTPS (unless you re-encrypted it).
There are a whole host of problems with #2, mostly about security and load. For example, instead of TWO robust servers handling their own HTTPS connections, now you're having ONE less-robust server / firewall trying to decrypt ALL the HTTPS traffic (and possibly re-encrypt it with different public keys), which adds a significant amount of load to your box.
If you choose NOT to re-encrypt the message as it goes between the firewall and the internal server, then there's a possibility of data exposure during that short internal trip (and that's the most likely place it will happen, too). It also means that the public-facing pfSense box would need to have the private key, so if the firewall ever got hacked, the malicious users would be much closer to being able to obtain that private key.
You'd have to weigh the risks and benefits, but it's usually FAR easier and FAR less-risky in the long run to simply pony up for a second IP.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Aside from Squid, nginx is also a good reverse proxy (and, coincidentally, a good normal web server, too) but I'm not sure how well it cooperates with pfSense (in terms of package management and updating and integration into the UI).
Still, you have a few options.
Still, you have a few options.
An addition to @gr8gonzo:
Historically it was true that SSL encrypted HTTPS contained the requested hostname inside the encrypted parts, so certificate negotiation was a pain. An extension to TLS/SSL is SNI (Server Name Identification) that solves this by sending the requested hostname before negotiating the certificates, so you can have one IP address with several HTTPS sites, without issues.
As the other say, put in a reverse proxy (the Microsoft IIS running your Exchange OWA is also an option for this) and you can distribute requests to different servers/URLs.
Tamas
Historically it was true that SSL encrypted HTTPS contained the requested hostname inside the encrypted parts, so certificate negotiation was a pain. An extension to TLS/SSL is SNI (Server Name Identification) that solves this by sending the requested hostname before negotiating the certificates, so you can have one IP address with several HTTPS sites, without issues.
As the other say, put in a reverse proxy (the Microsoft IIS running your Exchange OWA is also an option for this) and you can distribute requests to different servers/URLs.
Tamas
TimotiSt's suggestion regarding SNI is a good one. The only catch to SNI is that it's a -relatively- new concept that has to be supported by the client-side browser. We're at a point where the vast majority of people probably use browsers that will support SNI, but there is still a small segment of users that won't support it and will end up not sending the hostname ahead of time via SNI and will end up going down the default path (possibly ending up at the wrong site).
Now, that's often times a completely acceptable solution, especially if you're prepared for it. That way, if someone calls in and complains about it ("I tried to go to site X and ended up at site Y!"), you can know exactly what the problem is and can tell them to upgrade to a newer browser. You can even do a browser check on the web pages and proactively inform them that they need to upgrade to a newer browser to avoid the issue.
Every new web technology is the same thing, though - it's a waiting game until "enough" people are on web browsers that support the new way of doing things. If you're okay with being an early adopter (maybe your user base is always going to be people with modern browsers), then you should be golden with that approach. If you need to support the random person who is still using Windows XP, then you might not want to use SNI, but you have to weigh the pros and cons.
Wikipedia currently has a nice little table of SNI compatibility on major browsers/platforms so you can check to see if there will be any compatibility/support problems for your situation.
Now, that's often times a completely acceptable solution, especially if you're prepared for it. That way, if someone calls in and complains about it ("I tried to go to site X and ended up at site Y!"), you can know exactly what the problem is and can tell them to upgrade to a newer browser. You can even do a browser check on the web pages and proactively inform them that they need to upgrade to a newer browser to avoid the issue.
Every new web technology is the same thing, though - it's a waiting game until "enough" people are on web browsers that support the new way of doing things. If you're okay with being an early adopter (maybe your user base is always going to be people with modern browsers), then you should be golden with that approach. If you need to support the random person who is still using Windows XP, then you might not want to use SNI, but you have to weigh the pros and cons.
Wikipedia currently has a nice little table of SNI compatibility on major browsers/platforms so you can check to see if there will be any compatibility/support problems for your situation.
About the only concern is Internet Explorer with Windows XP (7% of the total market)
ASKER
Would any one know how exactly to set up SNI on IIS or NGIX or does any one have a guide to reverse proxy with SNI?
Without SNI support the user won't end up on the wrong site, just the SSL/TLS negotiation will be done with the default certificate, resulting in a warning. It's unfortunate, but fairly commonplace on the net anyway...
In the past years we only had one client running IE6 on Win2000, so had to accommodate, but since then even XP is EOL for 2 years now, so I wouldn't worry about XP+IE7 users. Firefox and Chrome do SNI on XP as well.
This seems sensible:
http://blog.lint.at/iis-as-reverseproxy-with-ssl-offloading/
In the past years we only had one client running IE6 on Win2000, so had to accommodate, but since then even XP is EOL for 2 years now, so I wouldn't worry about XP+IE7 users. Firefox and Chrome do SNI on XP as well.
This seems sensible:
http://blog.lint.at/iis-as-reverseproxy-with-ssl-offloading/
Ummmm... why did you pick #41557242 as the answer? I provided an answer (#41557217) that included a reverse proxy as the second option:
"You can set up a Squid proxy server on your pfSense server..."
"You can set up a Squid proxy server on your pfSense server..."
What I would do is: all DNS entries points to your public IP address, in which you have a web-server which, depending on the URL redirects to one site or another.
You need some web programming knowladge to do this, but a good start point could be this link:
https://en.wikipedia.org/wiki/URL_redirection
Hope it helps. Regards