I'm not sure I understand your comment - it seems to just restate what I said. The HOST is either a domain (which includes subdomains) or an IP Address.
1 Like
IIRC actually for SNI it will always be a name. If a client doesnât know the name it wants, for example because the URL it was trying to resolve contains an explicit IP address not a name, then it doesnât specify one at all. The IP address is not to be provided as substitute for a name.
Weâre both right and wrong on this, as I think weâre talking about different things.
No matter the implementation, an IP address would be visible on the transport layer. Even with encryption, a MITM/packet-sniffer is assured to know the source and destination ip addresses.
If a server is configured to use SNI for a domain, the domain name is transmitted unencrypted. The client might not request the IP as part of the SNI handshake, but itâs visible on the transport layer and, IIRC, you can still configure most servers to serve something on the IP by default.
2 Likes
great article on topic:
They start with a link-baity title, but explain the benefits pretty well.
1 Like
I donât think anyone has really mentioned it yet, but a great benefit from having communications encrypted is that every communication is encrypted, boring or not. If you treat encryption as something only reserved for important communications, it becomes very easy to pick out potentially interesting/sensitive communications: just pick out the encrypted ones. By encrypting everything (or most of it), youâve just added tons of noise and now someone trying to find sensitive communications will have a much much harder time doing so.
In addition, encrypted communications prevents man-in-the-middle content injections like Verizon Wirelessâ tracking header, advertising banner injections, and other nuisances like deep packet inspection.
Obviously, simply using HTTPS by itself wonât protect against state attackers (they can in theory force a CA to issue certs and MITM the connection), and it certainly wonât secure the website or the user themselves. There are other solutions to those issues. What it will do, however, is make sure that any communications between the ends canât be easily found out. Making that happen everywhere will obfuscate the truly important communications when those happen. That alone is a worthy and beneficial result.
Having read this thread in its entirety up to this point, I find that the fundamental reasons stated in the thread are essentially the same reasons I finally chose to go 100% for my sites. However, the elaborations in some linked sites let me learn some eye-opening facts. As OP, I promised to share my own rationale for going 100% secure with an LE cert. Herein, my follow-up.
My personal rationale was informed by first reconsidering the overall functions of TLS (and its predecessor SSL). I did this mainly by reviewing the Wikipedia article on TLS:
[quote]The primary goal of the Transport Layer Security protocol is to provide privacy and data integrity between two communicating computer applications...
...The connection is reliable because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.[/quote]
The emphasis was added by me. As stated in the opening post, I was initially puzzled about the LE objective of universal encryption of non-private websites. Privacy of communication is a concept with which I am long familiar. This goes back to a time when I served in a branch of US military intelligence in which I reported operationally (both technically and literally) to an agency sometimes known euphemistically as "No Such Agency". (Way, way, way back more years than I usually like to admit, during the Cold War. Decades before the internet existed.) Needless to say, my interest then was the opposite of privacy. 
I chose to omit sections of the description on Wikipedia that were primarily related to privacy, since that is a well-understood---by just about everybody---reason for TLS.
I had not previously given any real thought to the integrity aspect provided by TLS. Reconsidering that aspect led me to the realization that data integrity alone could provide sufficient justification, even when privacy was not a concern. Although, I didn't spend a lot of time considering the various ways in which compromise of data integrity could be harmful in some sense to either the server or the client, even when the information content is totally innocuous and fully public. This thread provided some really profound elaborations of that threat.
Interestingly, I was mindful, and keen on avoiding, some of the issues spelled out in the link posted by vizzaccaro:
In particular, these remarks succintly phrase the concerns I had:
Therefore, the integrity justification alone would still not have convinced me were it not for the fact that once I fully understood how to apply "certbot" to my particular circumstances, and in particular, the ease with which I could include all of my domains on one certificate, the entire process became completely hassle-free; and the scheme I adopted neatly avoids any broken links my users may have preserved..
(A description of the particular scheme I worked out would probably be of interest to a segment of would-be LE users, but is not directly germane to this thread so I will post that where it might be more likely to be of interest.)
I think itâs quite important if users submit secure information into your website such as, credit card/debit card numbers, private messages, bank information, various other confidential information, passwords if the site is big and money making etc⌠unless I donât think there is a point of securing the site further with a SSL cert. Beside encryption has some overhead, as I have noticed it delays the request and the response slightly, certs are also expensive, it may time consuming to implement a cert in the site, if itâs a forum or something the chances are that the site ends up showing some ugly message with a security warning about mixed contents as users can post whatever they want copying from anywhere. Therefore, itâs not really worth if the site doesnât belong to any of the categories I have mentioned above. Some sites only use the SSL cert in the sign up and the login pages and keep the rest plain without securing as there is nothing to secure to increase the siteâs performance. However. I want to be honest that, I like the the green bar which comes with the EV certs, I know itâs quite silly and just a gimmick though it may still be useful to certain people who want to verify the legitimacy of the the site at first glance. I think it makes the site beautiful, gives it a legitimate look, implies that site owner is very serious about their business or whatever they are doing. Unfortunately they are so expensive, I have been searching all over the internet for a cheap cert (under $20 per year), but I couldnât find any. wish I could afford for an EV cert for my site.
Itâs important to protect even âa simple forumâ. If the user has the bad habit to reuse the password, using http may compromise other more important accounts. Or somebody can impersonate the forum users, that could have legal implications.
Protecting only login and registration page made the login page useless, because other pages canât be sure itâs the same user (firesheep, anybody?), and it means an attacker can inject fake login form in any other page, or do a sslstrip attack.
And, under the European law, there is an obligation of protection for personal data, not only âbank informationâ.
Itâs like securing a small home with laser detectors, metal doors etc⌠waste of money, time and resources.
Yeah sure the things you mentioned can happen, but not many people can do something advanced like that, they need the skills, knowledge and people like that donât hack into small forums where people chat and share what they know.
2 Likes
@CutaInfo No, using https it's just having a lock on your door, or just having a door...
Key pinning, TLS1.2 only, must-staple, require-ct, yes, all that are for a blog what you say: like small home with laser detectors.
What I say is not science fiction:
- At security events there is sniffer that collect passwords: Feds at DefCon Alarmed After RFIDs Scanned | WIRED
Each year the Wall of Sheep
volunteers sniff DefConâs wireless network for unencrypted passwords
and other data attendees send in the clear and project the IP addresses,
login names and truncated versions of the passwords onto a conference
wall to raise awareness about information security.
-
There is rogues tor nodes that inject viruses: http://www.cbronline.com/news/cybersecurity/data/tor-exit-node-hacked-to-inject-malicious-code-in-downloads-291014-4420718
-
There is malicious ISP that inject ads: Code injection: A new low for ISPs | InfoWorld
-
There is You Can Get Hacked Just By Watching This Cat Video on YouTube - The Intercept
Should I continue?
2 Likes
I donât use passwords in my website, I use something which is more advanced than the passwords/username method. http://cuta.info/wp-login.php
Since you never type any password in the site, no one can ever collect any password from it.
However, because you donât have HTTPS, a visitor to âyourâ site can instead be presented with a fake that looks exactly like it. The fake site could easily use their CLEF to log into some other site (showing its wave instead of yours), any CLEF site thatâs not protected by HTTPS is certainly a possible target, and then it would be authenticated âas themâ and able to do anything on that site, even though they donât realise they ever logged in there. Or they could do that to your site, maybe your user syncs their wave, everything seems fine, then it displays âError. Sorry, please try laterâ but unknown to them now a bad guy has control.
Things like CLEF are a good idea, but they arenât substitutes for HTTPS.
2 Likes
Pretty much all the points you make are addressed in the Ars article. With Letâs Encrypt, certificates are free, and once itâs set up properly (using a client like letsencrypt.sh or acme.sh, this might take all of an hour), renewals happen automatically so you donât need to worry about your TLS cert again. HTTPS doesnât need to be significantly slower than HTTP (and I think itâs been shown up-thread that it can even be faster).
EV certs are likely always going to be expensive due to the validation required before they can be issued.
The fundamental issue, AFAIC, is that nobody else has any business knowing what Iâm doing online. HTTPS is one way (not the only way, and not a certain way) to help that happen.
3 Likes
No, it hasn't. There was a vague comparison between apples and oranges but nothing else.
What has been shown is that HTTPS isn't a big enough performance hog to counter the massive improvements you gain via pipelining and HTTP/2, which is nice but doesn't tell you anything.
In reality, HTTPS doesn't cause massive slowdowns anymore and you can basically always use it without worrying about performance much, but to say "something plus encryption" can be faster than just "something" is simply wrong.
@tdelmas, another case Iâve been wondering about is whether there are worms and/or botnets that are known to infect wifi routers in order to attack wifi network users (and infect their computers, making them part of a botnet). While this is certainly possible, I donât know whether itâs been observed in the wild yet.
2 Likes
It's not far from what's already happening:
1 Like
Encrypting a webpage does not deter from scraping, as page must be visible to users as well as bots.
As anyone can get a letsencrypt certificate, it does not prove anything.
I can buy dulcecabana.com, get a nice certificate, and it will look perfectly fine to anyone who canât se, or donât care about the difference between real and fake sneakers.
For his own domain only.
It proves that the content is securely exchanged with that domain.
If you should trust the domain or not is another question.
1 Like
My server says it is still http/1.1 I am wondering, if I added a cert to the site and turned it into a https one can I have http/2? I heard that it gives a fast performance.
I think domain verification is to verify the ownership of the domain and encrypt the connection between the server and the people. However, the authenticity of the organizationâs website is verified with the EV certs. I recently bought an EV cert, but unfortunately I canât use it since my site isnât a registered company 
no green bar for me.