I have an IIS 6.0 server and I'm no longer using an SSL certificate (Don't need it anymore because of some functional changes, don't have a valid one I can use). Is there a way for me to redirect users to the http site who already have the https one bookmarked?
I tried using a self signed certificate and rewriting the URL to the http version but browsers get a warning about the self signed certificate before I can redirect using web.config.
I also tried removing port 443 as an HTTPS binding and adding port 443 as an HTTP binding but it didn't work. When I tried to start the web site I got an error indicating the port was already in use.
No, you can't.
Redirections from HTTPS to HTTP happen after the initial HTTPS request has been made, and this request expects a valid certificate to be used.
If what you'd like to do was possible, downgrade MITM attacks would be far too easy to perform.
Perhaps turning off port 443 completely might make your users try plain HTTP too, although they really should consider this to be a potential attack if they don't know your site.
It is not possible what you want because it first has to do the SSL connect (which causes the warning) before it gets the HTTP redirect. And, this questions is asked nearly daily so you should have find enough answers to it.
Related
Recently I have installed ssl certificate on my website. After the ssl certificates have been installed ,I found that my subdomain is not working properly. I will address my subdomain as 'xxxx'and main domain as 'primary'. The main domain works well with http as well as https. Now the subdomain works well with http, but with https://xxxx.primary.com delivers me the main site content and not the content of subdomain. I'm using apache server, linux operating system.
Can anyone please help to solve this issue?
Thanks in advance.
This is how SSL protocol works with the browsers. Whenever browsers receive HTTPS request for domain name, it first checks with the server then delivers the site's content. If a website on server has enabled SSL accessed with HTTPS, browser will try to make secure connection and send request to the server.
In your case, your main website is working properly with HTTP as well as HTTPS and delivers proper content, but your sub-domain is not showing proper content for HTTPS. In order to deliver proper content you should consult with your development team. You can better host your sub-domain on another server or you can protect your sub-domain with valid separate SSL certificate.
Suggestion: If you own multiple sub-domains then it is advisable to use Wildcard SSL, that can protect unlimited number of sub-domains with single certificates. Please note, this unlimited does secure first level (blog.domain.com), doesn't second-third-fourth-etc. level (news.blog.domain.com, 1.news.blog.domain.com or abc.1.news.blog.domain.com).
An issue I have been experiencing is that once every ~50 pages I load in Google chrome on my website is that chrome gives me an error page saying SSL Protocol Error. I am using Flexible SSL and various webapps, like webmin, vestacp, boxbilling and a few mostly static websites. All of these are hosted by nginx, reverse proxying directly to webmin and vestacp. As for the other webapps, the static files are hosted by nginx, reverse proxying to apache2 for php.
I am not entirely sure it is a cloudflare issue yet, but it does (seem to) work normal making plain http requests directly to my server. Of course I'd be surprised if I got any SSL error when using http.
The server request is being proxied through CloudFlare, as long as it is proxied through CloudFlare this issue lies with CloudFlare and there is little you can do to fix it yourself.
I would raise a support request with them and explain the issue, they give preference to clients who pay the most first, therefore you might have to wait to get a response.
Is there a https header on the server, or JavaScript method in the browser, that will let us detect when the user has intentionally bypassed the security certificate, or any other way to detect and report this kind of situation? (We are using Linux / Apache / jQuery.)
The Web is filled with ways to routinely skip the warning, but I haven't been able to find a single thing about detecting when users skip it - just the horrifying statistic that 70% of users bypass the warning as quick as they can. (How do they measure that?)
We operate a web application that lets teachers make and administer tests. Teachers are connecting to unauthorized WiFi networks, getting invalid certificate warnings, and clicking on the browser's "accept anyway" feature so they can get to our application despite having certificate that is not authenticated. We want to understand how often this happens, and who is doing it, and progress to stopping it.
I should note that there are schools that proxy requests through their own server, with their own certificate, and we are OK with this - it's the "ignore and connect anyway" connections that we want to measure and mitigate, because those are the ones that students are setting up, without access to their own CA but ample access to lazy users.
One way to make sure that the client has seen the server certificate you sent is to use client-certificate authentication. One of the last steps of the SSL/TLS handshake when using client-certificate authentication consists of a hash of all the handshake messages signed with the client's private key.
A side effect of this is that, if the client didn't see the exact same server certificate, the server wouldn't be able to validate this signed hash coming from the client.
This certainly doesn't necessarily mean that the client checked the certificate as it should have (i.e. whether the certificate was trusted and belonged to the server the client intended to contact), but at least the server has a way there was no fake cert in the middle.
HSTS (which you mention) also has a way to make the client enforce these checks (see Section 8.4 of RFC 6797). However, it only works if the client already knows HSTS needs to be used (either as a pre-loaded host, or after a first visit), and of course relies on the client supporting HSTS (browser support is still limited).
Not sure what you mean by bypassing HTTPS. If you mean they can visit your URI without HTTPS, that means you need to block HTTP access in Apache's .htaccess, httpd.conf, or default-ssl config files. Broken padlock could mean a number of different things so it's not clear which problem you're having. You can test your site for SSL security problems here:
https://www.ssllabs.com/ssltest/
Edit:
You can compare the fingerprint of the SSL certificate on the server and on the client to make sure they match (if the client is able to get the fingerprint). That should prevent man-in-the-middle attacks with bogus certificates.
Article
and here's an answer for doing this on the server side of things. It sounds like the best way to avoid interception is to authenticate the client with their own certificate.
There is no way to detect this - the user is the only one who can see if the padlock is green and locked or red and broken.
Firefox will do this by extension and through xhtml, but it is, as of now, the only browser to support this.
I was looking for HSTS. Here is how it works and how to implement it.
TL;DR: Header add Strict-Transport-Security "max-age=15768000 includeSubDomains"
I currently have a website that use to have an SSL so the web address started with https://
I moved the website to a new server and platform which doesn't have an SSL so the web address starts with http://
I have inbound links going to the https address that I am wanting to redirect to the new website http url. Is this possible without me having to reinstall a new SSL on the new server? Is so, what could a possible solution be?
I have searched and found some promising stuff, but nothing worked. The hosting account is running on Cpanel v11.38.2 and Apache v2.2.23. Thank you for any insight, it is greatly appreciated!
Regards
To accept an HTTPS connection even only to return a redirect, you must still accept HTTPS connections in the first place, which means you need HTTPS installed and turned-on, either with a real certificate or a self-signed one.
For details on how to achieve the actual redirection, perhaps this question can help you: How do you redirect HTTPS to HTTP?
Is there anything wrong with configuring a webserver to map SSL traffic (port 443) to the same document root as normal traffic (port 80)?
Using the same document root for both http and https means you need to implement the following:
On each page that needs to be secure, there needs to be some application code that redirects the user to the https version if they somehow got to the http version (or to rediect the user to the login page if they have no session).
The login page always needs to redirect to the https version.
For pages that are accessible via both http and https, you need to set a canonical URL to ensure it doesn't appear like you have duplicate content.
Is there a better way to configure encryption of user account pages? Is there a best practice to separate website into HTTP and HTTPS sections?
It's not necessarily wrong to do this, but as your points 1..3 show, it introduces complications. It seems to me that setting up a separate document root might be a lot simpler than working around the complications.
In Internet Information Server 7.X you can define a "secure path" which is require to access with HTTPS and you can redirect the user to a user-friendly error page.
Maybe this can be a good solution to mix the document root and keep parts of the application secured.
Redirecting http automatically to https allows for man-in-the-middle attacks and is therefore not recommended. A man-in-the-middle could manipulate your HTTP traffic to send you to a malicious HTTPS site that resembles your HTTPS content.