Depends on how you define "wrong". The S stands for secure, that's been pounded into people's heads. HTTP 1 and 2 are miles apart and get the same protocol marker. So a secure connection with TLS gets shown as HTTPS, and an insecure connection with TLS gets shown as HTTP.
> The S stands for secure, that's been pounded into people's heads.
The S stands for "this connection is on port 443 and has been negotiated with TLS". That means it's being encrypted and has been authenticated.
> HTTP 1 and 2 are miles apart and get the same protocol marker.
Which was and is a terrible terrible idea and among the many reasons I dislike HTTP2.
> So a secure connection with TLS gets shown as HTTPS, and an insecure connection with TLS gets shown as HTTP.
Which is a terrible terrible idea. The protocol marker should denote the protocol used, not some fluffy stuff that doesn't really mean anything to the user.
>That means it's being encrypted and has been authenticated.
Except that TLS does not always imply encrypted and authentication. You can use TLS with a self-signed cert. You can use TLS with a broken cipher. You can use SSL_NULL_WITH_NULL_NULL. Browsers will helpfully provide things like a slash through the https in cases like this.
Whether the connection is actually encrypted and authenticated is what the vast majority of users care about. I'm not sure how you can call that fluff.
(Now as far as http 2, it's tricky because it's kind of at a lower layer that still runs http on top. And when you're linking to something you don't care about whether that layer exists. So there are pluses and minuses to having http2:// or spdy:// or whatnot. Not that any of that matters, because cocksure middleboxes nearly force it to continue to use http://.)
And your point is? If there is no port specified, that's what it's on if the protocol is HTTPS?
> You can use TLS with a broken cipher. You can use SSL_NULL_WITH_NULL_NULL. Browsers will helpfully provide things like a slash through the https in cases like this.
As they should, because allowing such things to happen automatically is contrary to what the spec is expecting to happen:
> If the hostname does not match the identity in the certificate, user
> oriented clients MUST either notify the user (clients MAY give the
> user the opportunity to continue with the connection in any case) or
> terminate the connection with a bad certificate error.
elsewhere
> In order to prevent this form of attack, users should carefully
> examine the certificate presented by the server to determine if it
> meets their expectations.
(for the second quote, the User Agent automates that process to make sure the certificate meets trust and expiration and the cipher suite meets exceptions.)
2. Certificate errors are much more confusing than a failure to connect.