4 ms·

But if someone clicks a link that says https:// https://, then the person who created that link wanted there to be authentication, so an error would be the corr

by Buge 12y ago

But if someone clicks a link that says https:// https://, then the person who created that link wanted there to be authentication, so an error would be the correct behavior.

Dylan16807 12y ago
1. Not true if that link replaced one that said http via an automatic process. Such as HTTPS Everywhere or a search engine doing the wrong thing. 2. Certificate errors are much more confusing than a failure to connect.
- jimktrains2 12y ago
  I don't want my UA showing me the wrong protocol though.
  - Dylan16807 12y ago
    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.
    - jimktrains2 12y ago
      > 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.
      - Dylan16807 12y ago
        > port 443 That's just a default. >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://. http://.)
        jimktrains2 12y ago
        > That's just a default. 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. - RFC 2818 "HTTP over TLS" (http://tools.ietf.org/html/rfc2818 http://tools.ietf.org/html/rfc2818) (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.)
dd0 12y ago
Why not just show an easily visible indication that says: >Connection is encrypted but authenticity cannot be confirmed. Connection is not secure unless you thrust the fingerprint!
- Buge 12y ago
  Because security is already confusing enough for the average user, and screen real estate is valuable. We don't need an extra type of distinction that they need to know. We don't want to have to say to someone, "before logging into your bank, make sure that it is https AND that there isn't some little warning somewhere about unconfirmed identity."
belorn 12y ago
Then create a new name, like ohttp. If it is the name of the protocol that is causing a roadblock for better security, then changing the name should be the obvious choice. Alternative we could always treat http as both being an unencrypted protocol and a opportunistic encrypted protocol.
- Buge 12y ago
  They are treating http as both being an unencrypted protocol and a opportunistic encrypted protocol.

by Buge 12y ago

But if someone clicks a link that says https:// https://, then the person who created that link wanted there to be authentication, so an error would be the correct behavior.

Dylan16807 12y ago

1. Not true if that link replaced one that said http via an automatic process. Such as HTTPS Everywhere or a search engine doing the wrong thing. 2. Certificate errors are much more confusing than a failure to connect.

jimktrains2 12y ago
I don't want my UA showing me the wrong protocol though.
- Dylan16807 12y ago
  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.
  - jimktrains2 12y ago
    > 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.
    - Dylan16807 12y ago
      > port 443 That's just a default. >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://. http://.)
      - jimktrains2 12y ago
        > That's just a default. 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. - RFC 2818 "HTTP over TLS" (http://tools.ietf.org/html/rfc2818 http://tools.ietf.org/html/rfc2818) (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.)

dd0 12y ago

Why not just show an easily visible indication that says: >Connection is encrypted but authenticity cannot be confirmed. Connection is not secure unless you thrust the fingerprint!

Buge 12y ago
Because security is already confusing enough for the average user, and screen real estate is valuable. We don't need an extra type of distinction that they need to know. We don't want to have to say to someone, "before logging into your bank, make sure that it is https AND that there isn't some little warning somewhere about unconfirmed identity."

belorn 12y ago

Then create a new name, like ohttp. If it is the name of the protocol that is causing a roadblock for better security, then changing the name should be the obvious choice. Alternative we could always treat http as both being an unencrypted protocol and a opportunistic encrypted protocol.

Buge 12y ago
They are treating http as both being an unencrypted protocol and a opportunistic encrypted protocol.