Hacker News new | past | comments | ask | show | jobs | submit login

You misunderstand the situation. It's entirely valid to serve one site on port 80 and another on port 443. Consider this scenario:

A webserver listening on a specific IP on port 80 and serving HTTP traffic, but using name based virtual hosting (reading the Host: header) to determine what site to deliver. We'll say it's configured for emample1.com and example2.com.

The same webserver (or a different one, it doesn't matter) listening on that same IP, but port 443, and serving HTTPS traffic. Without use of some newer SSL/TLS/HTTPS protocol features (which aren't universally supported), the certificate needs to be served before any regular HTTP traffic is sent across the encrypted tunnel. Which cert do you serve?

You can argue that it's probably good practice to not have named based virtual sites on the same IP as SSL sites, or that if you access the SSL site with the wrong hostname it should respond in error, and I think you would be correct.

But agreeing on best practices doesn't mean the site is set up wrong, just that it could be set up in a more robust way. It my be set up in a perfectly valid configuration.

It's wrong to assume when you can access a site on port 80 that if that same IP address responds to port 443 that it should serve the same site.

> The software I utilize checks that, they got it wrong. Return 404 instead.

The software you use should be checking that the cert served matches the site requested, and not try to upgrade the connection to HTTPS if it doesn't.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: