Feels like old man shouts at cloud. The benefits of browsers showing a scary screen when they go on http sites vastly outweighs the downsides. TLS isn’t perfect but it’s really the least we can...
Feels like old man shouts at cloud. The benefits of browsers showing a scary screen when they go on http sites vastly outweighs the downsides. TLS isn’t perfect but it’s really the least we can do. Calling it securitymaxxing is like railing against your front door having a lock.
He makes a great point though that the HTTP mechanism used by LetsEncrypt to verify ownership is itself vulnerable to MITM attacks. I wonder if the other challenge techniques are as similarly...
He makes a great point though that the HTTP mechanism used by LetsEncrypt to verify ownership is itself vulnerable to MITM attacks. I wonder if the other challenge techniques are as similarly insecure.
I am considerably less worried about a server administrator being MITM attacked in a connection to LetsEncrypt than I am about my grandmother getting one while logging into her bank. It’s not just...
I am considerably less worried about a server administrator being MITM attacked in a connection to LetsEncrypt than I am about my grandmother getting one while logging into her bank.
It’s not just MITM attacks either, SSL prevents the contents of your packets from being read by anyone on the same network or in the chain. While that’s irrelevant to Tom7.org, it’s not like chrome can detect the importance of the website you’re going on. Better to protect everything than try to do some Swiss cheese firewall.
All that, for what, so old lazy people who run meaningless websites don’t need to read letsencrypt docs for 5 minutes?
Heck at this point just use caddy if you don't want to deal with handling it yourself.I was one of those people that put off doing it for a long time, but finally broke down and got letsencrypt...
Heck at this point just use caddy if you don't want to deal with handling it yourself.I was one of those people that put off doing it for a long time, but finally broke down and got letsencrypt working on my nginx setup. Once i learned about Caddy i moved my site to that and it's hard to make excuses for not using SSL when it's done entirely automatic.
I like the video and I like Tom, super interesting and accomplished person. The video is provocative and that provocation is useful in that it's useful to ask people to re-examine the base...
Exemplary
I like the video and I like Tom, super interesting and accomplished person. The video is provocative and that provocation is useful in that it's useful to ask people to re-examine the base assumptions every once in a while. Laying out my own biases, I work in areas related to security and privacy but wouldn't consider myself an expert. Having said all that, I have a fair number of disagreements with Tom's complaints.
First, Tom lumps https and warnings about https in with other user hostile design to lock people into specific vendors. This is a category error - not every annoyance is vendor lock in or bad friction put there maliciously to extract something from users. No company wants to deal with HTTPS and if they didn't think it necessary they would not have it. Chrome and other browsers added those frictions because it addressed real user harm and mitigated actual attacks (ISPs inserting ads into web pages, public wifi snooping, government data collection, phishing attacks). I'm fine with quibbling about how the interstitial should look (I hate that the proceed is pushed to behind advanced too), but ultimately I do buy that users need some protection from taking unwittingly risky actions and that the friction does more good than harm.
Second, Tom seems to believe that because a server could be compromised or MITM'ed during ACME to establish domain ownership that this is hypocrisy and equivalent to any other MITM attack later on. I'm not particularly convinced by this argument, forward security is still good and website owners are in a much better position to notice and correct that attack than a random user. Users also face different MITM adversaries than server owners do. I'm not setting up a server over public wifi, but users will connect to the website from there. Making any MITM attack harder to accomplish seems like a very worthy goal to me.
Third, Tom downplays the connection between security and privacy. Banks are not the only sites that need security. You need security in order to have privacy and even a static site should still protect outsiders from seeing what content was accessed.
Fourth, there's a fair bit of bashing of CAs. I agree that CAs have bad track records and should be policed better. I also don't like the hierarchical nature involved. But, trust on the internet is hard and this is hardly the only hierarchical or centralizing portion (DNS, ISPs, browsers, search, social media network effects). Relative to other effects CAs are pretty unimportant. The internet is a giant game of picking entities to trust who then delegate that trust out further. I don't think there's any unequivocally better alternatives, let alone better alternatives for non technically savvy users. It's impressive that we at least get the level of control to pick who we root our trust in. If users pick Microsoft or Google or Apple or Mozilla as that entity then that's a valid choice and likely far better as a practical matter than asking users to make individual decisions about trust on the internet. If Tom wants to pursue different sources of root trust, he's able to do so.
Ultimately, I'm sympathetic to the general complaints about centralization and some of the specific complaints about HTTPS in particular, but I don't like the framing.
I'll grant chrome some credit for swapping the "padlock" icon for the "tune" icon they currently use. They call out specifically that they wanted to avoid implying that a site is "trustworthy"...
I'll grant chrome some credit for swapping the "padlock" icon for the "tune" icon they currently use. They call out specifically that they wanted to avoid implying that a site is "trustworthy" just because they support HTTPS.
I thought that no one can force me as well. Actually, I forced myself. One of my friends got Pixel 9a and used Chrome. And Chrome didn't surprise at all - default seems to be se to "http no go"....
I thought that no one can force me as well. Actually, I forced myself. One of my friends got Pixel 9a and used Chrome. And Chrome didn't surprise at all - default seems to be se to "http no go". Once I set up HTTPS it works.
Feels like old man shouts at cloud. The benefits of browsers showing a scary screen when they go on http sites vastly outweighs the downsides. TLS isn’t perfect but it’s really the least we can do. Calling it securitymaxxing is like railing against your front door having a lock.
He makes a great point though that the HTTP mechanism used by LetsEncrypt to verify ownership is itself vulnerable to MITM attacks. I wonder if the other challenge techniques are as similarly insecure.
I am considerably less worried about a server administrator being MITM attacked in a connection to LetsEncrypt than I am about my grandmother getting one while logging into her bank.
It’s not just MITM attacks either, SSL prevents the contents of your packets from being read by anyone on the same network or in the chain. While that’s irrelevant to Tom7.org, it’s not like chrome can detect the importance of the website you’re going on. Better to protect everything than try to do some Swiss cheese firewall.
All that, for what, so old lazy people who run meaningless websites don’t need to read letsencrypt docs for 5 minutes?
Heck at this point just use caddy if you don't want to deal with handling it yourself.I was one of those people that put off doing it for a long time, but finally broke down and got letsencrypt working on my nginx setup. Once i learned about Caddy i moved my site to that and it's hard to make excuses for not using SSL when it's done entirely automatic.
I like the video and I like Tom, super interesting and accomplished person. The video is provocative and that provocation is useful in that it's useful to ask people to re-examine the base assumptions every once in a while. Laying out my own biases, I work in areas related to security and privacy but wouldn't consider myself an expert. Having said all that, I have a fair number of disagreements with Tom's complaints.
First, Tom lumps https and warnings about https in with other user hostile design to lock people into specific vendors. This is a category error - not every annoyance is vendor lock in or bad friction put there maliciously to extract something from users. No company wants to deal with HTTPS and if they didn't think it necessary they would not have it. Chrome and other browsers added those frictions because it addressed real user harm and mitigated actual attacks (ISPs inserting ads into web pages, public wifi snooping, government data collection, phishing attacks). I'm fine with quibbling about how the interstitial should look (I hate that the proceed is pushed to behind advanced too), but ultimately I do buy that users need some protection from taking unwittingly risky actions and that the friction does more good than harm.
Second, Tom seems to believe that because a server could be compromised or MITM'ed during ACME to establish domain ownership that this is hypocrisy and equivalent to any other MITM attack later on. I'm not particularly convinced by this argument, forward security is still good and website owners are in a much better position to notice and correct that attack than a random user. Users also face different MITM adversaries than server owners do. I'm not setting up a server over public wifi, but users will connect to the website from there. Making any MITM attack harder to accomplish seems like a very worthy goal to me.
Third, Tom downplays the connection between security and privacy. Banks are not the only sites that need security. You need security in order to have privacy and even a static site should still protect outsiders from seeing what content was accessed.
Fourth, there's a fair bit of bashing of CAs. I agree that CAs have bad track records and should be policed better. I also don't like the hierarchical nature involved. But, trust on the internet is hard and this is hardly the only hierarchical or centralizing portion (DNS, ISPs, browsers, search, social media network effects). Relative to other effects CAs are pretty unimportant. The internet is a giant game of picking entities to trust who then delegate that trust out further. I don't think there's any unequivocally better alternatives, let alone better alternatives for non technically savvy users. It's impressive that we at least get the level of control to pick who we root our trust in. If users pick Microsoft or Google or Apple or Mozilla as that entity then that's a valid choice and likely far better as a practical matter than asking users to make individual decisions about trust on the internet. If Tom wants to pursue different sources of root trust, he's able to do so.
Ultimately, I'm sympathetic to the general complaints about centralization and some of the specific complaints about HTTPS in particular, but I don't like the framing.
I'll grant chrome some credit for swapping the "padlock" icon for the "tune" icon they currently use. They call out specifically that they wanted to avoid implying that a site is "trustworthy" just because they support HTTPS.
https://blog.chromium.org/2023/05/an-update-on-lock-icon.html
Link to the accompanying paper: https://tom7.org/httpv/httpv.pdf
Which is hosted on his insecurely-secured website. So, y'know, be careful of those hooded hackers finding out that you visited Tom7.org
"You are securely connected to this site" says Firefox. Oh how naive you are, Firefox.
I thought that no one can force me as well. Actually, I forced myself. One of my friends got Pixel 9a and used Chrome. And Chrome didn't surprise at all - default seems to be se to "http no go". Once I set up HTTPS it works.