Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
When I go to https://www.schneier.com/, everything works normal.
As soon as I access the same site using its IP address (66.33.204.254), I get a security warning (even if I write something like https://66.33.204.254:443/).
The same is not true for google.com (I'm using this IP address: 216.58.211.14)
Why is that? How are these two sites different?
UPD: Here's the GIF of what I see when entering Google's IP, no warning there: http://www.giphy.com/gifs/26gYMNRlBYy9yAYnu
It's because you generally create a TLS Certificate for an hostname, not an IP. Changing IP addresses is trivial, changing domains are not that common.
If you open the site in Firefox using IP, you will see this message:
66.33.204.254 uses an invalid security certificate.
The certificate is only valid for the following names:
schneier.com, www.schneier.com
Opening 216.58.211.14 (Google) will give the same message.
curl -LI 216.58.211.14 (my result: paste.ubuntu.com/23784846). Google first redirects from the IP to http://www.google.com and then to the local Google site. In Chrome, because Google uses HSTS, the browser does a 307 redirect to the HTTPS site when it encounters the first redirect: i.stack.imgur.com/MkgWJ.png Schneier's site simply redirects to HTTPS, not to a particular domain.
The error indicates that you have reached a site that cannot prove it owns the address that you entered in the address bar.
Imagine this. You visit https://www.google.com. You check the certificate for the connection and discover that it was actually issued to www.DeathToAmerica.ru. This is a strong indication that your browser hasn't actually reached google.com. Instead, your communications have been intercepted in what is known as a Man in the Middle(MitM) Attack. Your communications are still encrypted, but they are being sent to (and decrypted by) an unknown entity.
To protect against this, your browser will automatically check the address that you entered against the certificate. Whenever they do not match, it will display the error that you are seeing.
Since you entered 66.33.204.254 but the certificate was issued to www.schneier.com you will get the error. This indicates that the site you have reached cannot prove that it owns 66.33.204.254.
Generally speaking, a CA will not issue a cert for an IP address. If you need to access a site that is not in DNS, and you must use https, and you don't want to see that error, I suggest you use a host entry.
The certificate is issued to a common name (CN), in your example schneier.com / *.google.com.
If you access the website using the IP address instead of the domain name this CN field will not match the authority part of your URL and your browser will return an error (like NET::ERR_CERT_COMMON_NAME_INVALID for Google Chrome).
If you are accessing the websites you mentioned via http, you are being redirected to the https equivalent. However, Google will redirect you to https://google.com whereas Schneier will redirect you to https://216.58.211.14. The former will not cause an error, the latter will (due to the reasons mentioned above).
So the effect you described is due to the configuration of the redirects on the two web servers.
http://216.58.211.14 (without TLS) google issues a redirect to https://www.google.com, which might explain why some users perceive that there is no error.
https://google.com whereas Schneier will redirect you to https://216.58.211.14. The former will not cause an error, the latter will (due to the reasons I mentioned). I will adjust my answer accordingly.
Jan 11, 2017 at 19:18
Most major accepted TLS/SSL certificates are issued to host names, which can be looked up via DNS.
The reason for this checking is to prevent potential Man in the Middle attacks, where an attack could have a perfectly valid certificate, but it isn't issued to the website you are attempting to visit. Certificates address the area of "non-repudiation".
In the case with google, they attempt to redirect users to the domain name as the IP address hosting the web service likely handles requests for many domain names (see the second code box below). The same thing would happen if you attempted to access a website which uses Cloudflare. Because Cloudflare is sitting in front of many websites, it doesn't know which to serve, and returns an error message.
66.33.204.254 uses an invalid security certificate.
The certificate is only valid for the following names:
schneier.com, www.schneier.com
Error code: SSL_ERROR_BAD_CERT_DOMAIN
Google will give the same error code:
216.58.211.14 uses an invalid security certificate.
The certificate is only valid for the following names:
*.google.com, *.android.com, *.appengine.google.com, *.cloud.google.com, *.google-analytics.com, *.google.ca, *.google.cl, *.google.co.in, *.google.co.jp, *.google.co.uk, *.google.com.ar, *.google.com.au, *.google.com.br, *.google.com.co, *.google.com.mx, *.google.com.tr, *.google.com.vn, *.google.de, *.google.es, *.google.fr, *.google.hu, *.google.it, *.google.nl, *.google.pl, *.google.pt, *.googleadapis.com, *.googleapis.cn, *.googlecommerce.com, *.googlevideo.com, *.gstatic.cn, *.gstatic.com, *.gvt1.com, *.gvt2.com, *.metric.gstatic.com, *.urchin.com, *.url.google.com, *.youtube-nocookie.com, *.youtube.com, *.youtubeeducation.com, *.ytimg.com, android.clients.google.com, android.com, developer.android.google.cn, g.co, goo.gl, google-analytics.com, google.com, googlecommerce.com, urchin.com, www.goo.gl, youtu.be, youtube.com, youtubeeducation.com
Error code: SSL_ERROR_BAD_CERT_DOMAIN
An image of what would happen when you access a site "protected" by cloudflare:
https://66.33.204.254/for schneier.com, so if you want comparable results you'll have to usehttps://216.58.211.14/for google.com.