Say I have an url that is served over HTTPS, but in my .htaccess I rewrite proxy it to another domain that is on the same server like so:
RewriteRule /https-url/(.*) http://www.somesite.com/$1 [P,L]
Is this a secure situation? I would assume it is, because the browser is communicating with an SSL secured url and the rewriting is done on the server where nobody can interfere.
EDIT: I just went on and tried it. It works just fine, you can just redirect people to https if they approach the http url directly. This has also saved me some money since I only had to buy an SSL certificate for one domain.
If www.somesite.com is hosted on the same server that the rule is being applied on, then it's network traffic is never leaving the server. That means a 3rd party not on the server won't be able to "eavesdrop" the contents of the request and response (or masquerade as a trusted party) so it doesn't matter if it's unencrypted. The assumption here is that if someone can get access to this traffic, they've already compromised the server so the reverse proxy may be the least of your worries.
Related
I am using CentOS Linux 7.3.1611 with Plesk Onyx 17.0.17 to forward (301) myolddomain.com to mynewdomain.com. mynewdomain.com has a valid SSL certificate.
However, if I go to https://myolddomain.com, then I get a certificate error and the domain does not get forwarded. How do I make https://myolddomain.com forward too. Do I need to host my old domain and use .htaccess to make the redirect? I don´t want to leave it as it is because that means having duplicate content and that´s obviously bad for SEO.
EDIT
The forwarding works fine for all non https requests.
This free service will forward the old domain to the new one...
https://redirect.pizza/
Once you set up the account there, you then need to update your A record and CNAME record in the DNS for the old domain to point to the redirect.pizza servers.
They use LetsEncrypt to generate the certificate for the old domain. I have been using it and it works perfectly.
Note that doing this could potentially let redirect.pizza put up anything they wanted on your old domain rather than forwarding to new domain, so you have to trust them. If you are worried about this, you could monitor the old domain and if they ever stop forwarding, then you could defensively update you DNS to no longer point to them.
You need to have a server at the old domain, and it has to have a valid certificate for the old domain name, in order to provide a redirect under https.
This is because of how https works. First the secure connection must be established, which requires the certificate. Only then can the http request and the redirect response be made.
I am making a self-hosted app, and I would like to require HTTPS since sensitive informations might be sent. How can I tell if client is using a secure connection ?
I could use javascript in the browser, but this wouldn't be secure (since an attacker could just bypass this)
The node server might be running as HTTP, but behind a secure nginx/apache proxy.
Optionnally, I would need to enforce this rule every time someone is making a request.
Well you can configure your web server so it redirects the user to the HTTPS url from a HTTP url. Apache htaccess is commonly used ensure that a website is accessible only over HTTPS. See this link for more information: http://www.askapache.com/htaccess/ssl-example-usage-in-htaccess/#redirect-http-to-https
We have a Windows Server 2008 with IIS. One of the sub domains (i.e. HTTPS.TEST.COM) is bound to https and the other sub domain is bound to http (i.e. HTTP.TEST.COM). If the user enters https://HTTP.TEST.COM the user gets an ugly error about incorrect certificate - for some reason IIS uses the certificate for HTTPS.TEST.COM because user typed https instead of http.
My question is, how do I make sure visits to https://HTTP.TEST.COM gets redirected to http://HTTP.TEST.COM? It is not necessary to redirect to same sub page, the important thing is to get rid of the ugly error message. I have seen other posts about URL rewrites, but I get the feeling there are easier ways to solve this.
That is not possible, because when the client first connects to the https port of the server, there is an SSL handshake that results in the server certificate being presented to the client before the client is even allowed to tell the server which URL it is trying to access.
It is the client that gives the error that the server certificate for does not match what is expected and this happens before the server can do a redirect to the correct subdomain.
However, if you place a wildcard certificate for *.test.com on the server, you can effectively bypass the error and get the redirection to work. Another way would be to have separate SSL certificates for both HTTP.TEST.COM and HTTPS.TEST.COM, but for the above reasons you must then have them on separate IP addresses.
I am hosting my public facing site at a shared host (Hostgator) with the domain pointing to the same. I also have my application hosted on a dedicated server with a different host. Both servers have their own SSL certificates installed.
Is there any way to edit the .htaccess file to do the following:
https://www.domain.com/CUSTOMER redirects to https://x.x.x.x/CUSTOMER while the browser still shows www.domain.com/CUSTOMER?
I'm vary of using frames due to the SSL ramifications. My domain registrar is Hostway and they do not offer URL masking/forwarding.
This can be done by making your server act as a proxy. Even if you have no access to the servers configuration you might be lucky that apaches proxy module is loaded: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
If so you can 'map' the remote site (IP) as if being served by your normal server.
Also apaches rewriting module can make use of that module by using the [P] flag in a RewriteRule.
Be sure you have a copy of that site on the different server, preverally with the same database, so you don't get in trouble with i.e. order numbers or user logins between http and https. The certificate server must be the web server for your SSL provided web content.
Take a look here foor further informations. "Google Search Result"
I recently moved servers and redeveloped the website at the same time. Previously all pages were served via https and I wanted to change this so only cart pages were via https. Also I wanted to clean up the url a bit. Old urls were:
https://secure.mydomain.com/onlinestore/index.php
and I removed the secure prefix and the subfolder so it is now:
http://www.mydomain.com/index.php
Problem is I wanted people who clicked on old links or bookmarks to be redirected to the new page. I got this working with htaccess. However the new SSL only covers the root domain and not the secure subdomain. So if someone clicks an old link it brings up "This Connection is Untrusted" before it can redirect. Works fine if i change https to http.
So what I want to know is if there is anyway I can force http instead of https before it checks the SSL cert.
Hope that makes sense!
The short answer is no. With conventional SSL, your web server doesn't even get to see the URL before certificate negotiation happens. It just sees a connection on port 443 and starts doing SSL negotiation. The browser then sees the mismatched cert and throws an exception.
However, more modern browsers and web servers (see Wikipedia for the list) support a TLS extension called Server Name Identification (SNI), which allows the client to send the hostname it's requesting before the server has to respond with a certificate. At that point you'll need to have certificates for both secure.mydomain.com and www.mydomain.com on that server, and it'll need to be configured to respond with the proper certificate.