Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doubts about 7.1.1. Opportunistic TLS #165

Open
polettix opened this issue Apr 27, 2018 · 2 comments
Open

Doubts about 7.1.1. Opportunistic TLS #165

polettix opened this issue Apr 27, 2018 · 2 comments

Comments

@polettix
Copy link

Section 7.1.1. Opportunistic TLS has this:

This is a somewhat debatable feature. Such a connection would do unauthenticated TLS and wouldn't be advertized as “secure” anywhere, wouldn't use any padlock in the UI, and in fact there is no way to tell the user that it isn't plain old HTTP, but this is still opportunistic TLS and some people are very firmly against this concept.

I have to admit that I find it a bit obscure - both sides of the debate seem to agree that it's a bad thing (or so I read it). Specific issues:

  • "Such a connection would do unauthenticated TLS..." how does this compare against a connection that was initiated directly with https?
  • "wouldn't use any padlock in the UI" this is obscure and possibly related to browser implementations that are not necessarily the only clients?
  • "there is no way to tell.." what isn't plain old HTTP exactly? The new connection where the user is being redirected to? Why would a client assume that? Why would a user?
  • all the above seem to be "CONS". The "but" part also seems to be against the feature. So... does it make sense at all?
@bagder
Copy link
Owner

bagder commented Apr 27, 2018

First, let's remember that this describes the state of the discussion as it was a few years ago.

how does this compare against a connection that was initiated directly with https?

HTTPS:// in the URL would imply authenticated TLS. That the name is verified against the certificate and the certificate is signed by a trusted CA. A secure connection.

wouldn't use any padlock in the UI" this is obscure

Maybe, but it is there to underscore that there would be nothing in the UI to hint or suggest that the connection would be secure.

"there is no way to tell.." what isn't plain old HTTP exactly? The new connection where the user is being redirected to? Why would a client assume that? Why would a user?

One of the strong arguments mentioned against opportunistic HTTPS back in the day was exactly that users would be satisfied with this level and thus not go all the way and do proper HTTPS for sites. Thus it seemed relevant to underscore that there would be no indication to users that it is "HTTPS", as it wouldn't be HTTPS as it otherwise works for clients.

@polettix
Copy link
Author

First, let's remember that this describes the state of the discussion as it was a few years ago.

Sure, it was not meant as a (non-constructive) critique. I really didn't understand the passage and I still doubt I'm understanding it properly.

I probably misread the whole paragraph like this:

YADDA YADDA it isn't plain old HTTP, but this is still opportunistic TLS and some people YADDA

instead of this:

YADDA YADDA it isn't plain old HTTP, but this is still opportunistic TLS and some people YADDA

i.e. the but refers only to the "it isn't plain old HTTP" and not to the whole sequence of arguments before.

It would help to have a simpler sentence structure like: "Some people are very firm against Opportunistic TLS because this, this and that as well".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants