7

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

  • 10
    the HTTPS cert names a domain, which mis-matches an IP address, even if that IP maps to the domain. Otherwise, sites couldn't change IPs without re-issuing certs; yuck. – dandavis Jan 11 '17 at 18:33
  • 4
    "The same is not true for google.com" Yes it is: 216.58.211.14 If you use the http site obviously it doesn't happen, but you're navigating to https://66.33.204.254/ for schneier.com, so if you want comparable results you'll have to use https://216.58.211.14/ for google.com. – Ajedi32 Jan 11 '17 at 20:08
  • Because his site was explicitly configured (*or misconfigured?) to do that. – Michael Hampton Jan 11 '17 at 23:22
15

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.

  • Strange, but opening 216.58.211.14 most certainly doesn't give me the same message on my computer both in Firefox and Chrome. – Pavel Vergeev Jan 11 '17 at 18:38
  • 1
    You accessed Google's IP using HTTP or HTTPS? – ThoriumBR Jan 11 '17 at 18:41
  • I just copied and pasted the IP, the same way I did with Schneier's IP. Google redirected me to HTTPS. – Pavel Vergeev Jan 11 '17 at 18:45
  • 1
    @PaulVergeev try 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. – muru Jan 12 '17 at 2:23
  • @muru Thank you, this explains a lot! Together with your comment, the answer is complete. – Pavel Vergeev Jan 12 '17 at 14:22
4

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.

  • Thank you for a thorough answer, but I still don't get it: how is google different? I've took a screenshot (giphy.com/gifs/26gYMNRlBYy9yAYnu) to show that there's no warning whatsoever for me. (By the way, thank you, got a good laugh from "deathtoamerica.ru"). – Pavel Vergeev Jan 11 '17 at 19:05
  • In your animated GIF, I can see that the IP address is redirecting your browser to https://google.ru, which apparently has a valid certificate that matches its address. – John Wu Jan 11 '17 at 19:23
  • 2
    @PaulVergeev You didn't type the https. If you go to 216.58.211.14 you will get the same error. – tlng05 Jan 11 '17 at 19:29
1

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.

  • 1
    If you access 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. – John Wu Jan 11 '17 at 18:43
  • I've added a GIF that shows my screen when I do that. – Pavel Vergeev Jan 11 '17 at 18:49
  • @JohnWu Why only some users? – Pavel Vergeev Jan 11 '17 at 18:50
  • Because some users are smarter than others. – John Wu Jan 11 '17 at 19:01
  • I missed the fact that you are accessing the websites via http and being redirected to https. If you do so 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 I mentioned). I will adjust my answer accordingly. – Hacktiker Jan 11 '17 at 19:18
0

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:

Cloudflare via IP

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.