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.
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'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.
Tangentially, there was a post on r/sysadmin recently talking about how ridiculous certs expirations are getting. More rant, but some discussion on the overall state of certs. I get where the...
I get where the author (I didn't watch the video, but rather read the paper) is coming from. Because sometimes things do feel like a bit of security theater. I remember like almost 15yrs ago, at the company I was at, having to pay like $800/yr for a cert on our proprietary vendor-hosted CMS. $800 isn't a lot for a business, but it still seemed really high. And IIRC, the reason we did it had something to do with SEO. Like instead of using the vendor's default SSL cert, which had their name on it, having our own SSL with our company name on it would help SEO. Idk, seemed ridiculous to me. Not even sure it actually helped our SEO at all.
But I also get the feeling the author doesn't work closely with the average everyday user. I could be wrong; maybe he does. However, since I am closer to users -- luckily not as close as I used to be -- I get that having guardrails up is better than having none.
I'm no longer a regular user of reddit, but that post mimics how I feel on the new radically shortened cert life expectancy. I have to deal with configuring an external cert, that I do not have...
I'm no longer a regular user of reddit, but that post mimics how I feel on the new radically shortened cert life expectancy. I have to deal with configuring an external cert, that I do not have any control over, into our load balancer because of a collaboration with a specific high value customer. I cannot automate it and the customer's IT team doesn't appear to have a path to do so either. I have been needing to baby step them through the process every time and it is only going to get much more annoying needing to do it more often.
A couple of reasons, but the biggest is that we (or I really) do not have access or authority to request certificates in their name and that won't change any time soon. So I can't set up anything...
A couple of reasons, but the biggest is that we (or I really) do not have access or authority to request certificates in their name and that won't change any time soon. So I can't set up anything to automate the process. I don't have a problem with any of the certs that we create because it is automated. Those will be fine with a shorter time span.
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.
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.
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'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.
Tangentially, there was a post on r/sysadmin recently talking about how ridiculous certs expirations are getting. More rant, but some discussion on the overall state of certs.
I get where the author (I didn't watch the video, but rather read the paper) is coming from. Because sometimes things do feel like a bit of security theater. I remember like almost 15yrs ago, at the company I was at, having to pay like $800/yr for a cert on our proprietary vendor-hosted CMS. $800 isn't a lot for a business, but it still seemed really high. And IIRC, the reason we did it had something to do with SEO. Like instead of using the vendor's default SSL cert, which had their name on it, having our own SSL with our company name on it would help SEO. Idk, seemed ridiculous to me. Not even sure it actually helped our SEO at all.
But I also get the feeling the author doesn't work closely with the average everyday user. I could be wrong; maybe he does. However, since I am closer to users -- luckily not as close as I used to be -- I get that having guardrails up is better than having none.
Fyi your link is broken
Fixed, thanks.
I'm no longer a regular user of reddit, but that post mimics how I feel on the new radically shortened cert life expectancy. I have to deal with configuring an external cert, that I do not have any control over, into our load balancer because of a collaboration with a specific high value customer. I cannot automate it and the customer's IT team doesn't appear to have a path to do so either. I have been needing to baby step them through the process every time and it is only going to get much more annoying needing to do it more often.
Why can't it be automated? IMO certificates should be perhaps as short as 24 hours in lifespan.
A couple of reasons, but the biggest is that we (or I really) do not have access or authority to request certificates in their name and that won't change any time soon. So I can't set up anything to automate the process. I don't have a problem with any of the certs that we create because it is automated. Those will be fine with a shorter time span.
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.