I do like them, but at the same time why do I have to encrypt my recipe site? I would like the option in my browser to not warn about sites that don’t use TLS. Or at least to be presented with an option? Oh, this is a reference recipe site. Would you like not to use encryption? Encryption is such a pita for simple things. I do think that sites that accept credentials always need to be encrypted, but why go through the hassle for things that are public? I am very thankful to let’s encrypt and the caddy web server for making certificates. A non-issue, but at the same time I kind of get tired of oh no it’s not encrypted properly warnings which everyone will ignore anyway.
Back in ~2012 users of our startup’s iPhone app complained that it crashed when they were on the London Underground (I think, I may be misremembering the details).
It turned out the WiFi down there was modifying HTML pages served over HTTP, and our app loaded HTML pages that included comments with additional instructions for how the app should treat the retrieved page… and those comments were being stripped out!
We fixed the bug by switching to serving those pages over HTTPS instead. I’ve used HTTPS for everything I’ve built since then.
I can sort of understand that since bandwidth was a premium in 2012, so if they could remove as many bytes from the payload as possible, then they increase their network bandwidth overall. Still surprising, but I could at least rationalize it.
No matter how much bandwidth you (an ISP) have, there are always schemes which promise to reduce your usage and thus improve the end-user experience – or invade their experience and make you money.
(Some of those schemes actually work. CDNs, for example.)
Interesting. I wonder if my memory is just off. NYC had really bad internet back then, as I recall, because our infrastructure is buried and expensive to upgrade. But I could swear we had like 100Mbps.
It’s not just ISPs, it’s any malicious actor, such as the operator of the wireless access point you’ve connected to (which may not be the person you think it is). You have a choice of either protecting visitors to your site from trivial interception and tampering or leaving them vulnerable. No one is forcing you to choose either way.
I originally chose to not enable TLS for our game’s asset CDN because checking certs on arbitrary Linux distros is ~unsolvable and we have our own manifest signing so we don’t need TLS’s security guarantees anyway, then we found some ISPs with broken caching that would serve the wrong file for a given URL, so I enabled it and disabled cert verification in the Linux client instead.
ISPs don’t even have to be malicious, just crappy…
It’s sort of self explanatory. Confidentiality and Integrity.
I know that I’m getting exactly the recipe that you are serving from your site
I know that no one else can see which recipe I’m cooking
I know that no one can inject ads, malicious code, tracking, malicious/ abusive images, etc.
If you aren’t willing to give those two things to your users I’m really convinced that you just aren’t in a position to host. Recipe site or not, we all have basic obligations. If you can’t meet them, that’s okay, you don’t have to host a website.
HTTPS leaks a lot less metadata than HTTP. With HTTP, you can see the full URL of the request. With HTTPS, you can see only the IP address. There’s a huge difference between knowing that I visited Wikipedia and that I read a specific Wikipedia page (the latter may be possible to determine based on the size of the response, but that’s harder). With SNI, the IP address may be shared by hundreds of domains and so a passive adversary doesn’t even see the specific host, let alone the specific page.
Usually SNI is sent in the clear, because the server needs to know the server name to be able to choose the right cert to present to the client, and it would require an extra round trip to do key exchange before certificate exchange.
There’s ongoing work on encrypted SNI (ESNI) but it requires complicated machinery to establish a pre-shared key; it only provides meaningful protection for mass virtual hosters (ugly push to centralize); and it’s of limited benefit without encrypted DNS (another hump on the camel).
Thanks, SNI does not work how I thought it worked. I assumed there was an initial unauthenticated key exchange and then the negotiated key was signed with the cert that the client said it wanted. I believe QUIC works this way, but I might be wrong there as well.
QUIC illustrated shows that the initial packet is encrypted with keys derived from a nonce that is sent in the clear in the initial packet; inside the wrapper is a TLS/1.3 client hello
I suppose this makes sense in that QUIC is designed to always encrypt, and it’s harder to accidentally send a cleartext packet if there aren’t any special cases that need cleartext. RFC 9000 says, “This protection does not provide confidentiality or integrity against attackers that can observe packets, but it does prevent attackers that cannot observe packets from spoofing Initial packets.”
I re-read the whole thread and I think it’s fair to say that a lot of the sentiment in the thread (a surprising amount of it) was quite openly anti-HTTPS.
Also I think your terminology is imprecise; I didn’t suggest ‘banning’ HTTP sites from Lobsters, only HTTP link submissions which would benefit from Lobster link juice. I actually said in the thread that users could just post a text submission and then link to it in a comment.
Here are the top scoring submissions with ‘http://’ in the URL since the date of your original discussion. All but 3 redirect to HTTPS. As before, I leave it to the community to decide whether forbidding these sites (because that’s what your original proposal amounted to) or requiring someone to jump through user hostile hoops (possibly triggering spam detection) would be worth it.
As to why someone submits a http link when there’s a https one available, maybe they got it from somewhere else (like HN)?
In summary: there’s a time and place to advocate for https only. Making this site worse to use is not that time nor place.
I’d accept an addition to the submission which would prompt the submitting user to add https (or add it automatically) if the title fetch check found an alternative. Not gonna code it myself though, life’s too short.
FWIW, in my experience there’s been a large vein of anti-HTTPS across lobsters outside of that thread.
(Not judging, I don’t care other than it wastes comment space when I also don’t care about avoiding HTTPS)
I think it’s safe to say that not being able to submit an HTTP-only link to Lobsters is kind of a ‘first-world problem’ as punishments go when modern browsers actually make people jump through hoops to visit HTTP-only sites (as they should, imho)
Regarding your proposal, I stand by the comment I made 2 years ago. But for what it’s worth I am appalled by the disrespect you show here in this thread.
I’m sorry, I don’t know what you are trying to achieve with comments like this, which are completely unproductive and very difficult (for me) to take seriously. It honestly sounds like pearl-clutching like ‘How dare you suggest something that might slightly inconvenience my desire to consume every possible article on the internet!’
This is a strange hill to die on. Yeah, more things should be HTTPS. There’s a bunch of older content that hasn’t been updated either. It’s not something I lose sleep at night over, nor do I think of what others think of that.
Nor do I, I just find it interesting then that so many others get completely riled up about it, as if I’m here to take away their puppy or something. If you look at gerikson’s comment above only a small fraction of the submissions people are interested in, are HTTP only. So as you point out–why lose sleep over making them slightly more inconvenient to submit?
I think a small minority is loudly against it and most people don’t care. Remember the anti-HTTPS sentiment I mentioned earlier? Fairly sure that’s at least part of it.
I’m not “anti-HTTPS”, but I don’t think there’s much point in limiting submitted links to HTTPS (maybe find the HTTPS version when possible). Again, a lot of older content is out there that hasn’t been updated. It’s a strange hobby horse to get obsessed with and accuse others over though.
Again, I’m not ‘obsessed’ with it or ‘accusing’ anyone of anything. I’ve brought it up twice in the past two years. I don’t know about you, but I don’t call that an obsession. You’re making it sound as if I’m irrationally pointing fingers at people and shouting ‘anti-HTTPS!’, lol. I just summarized some of the arguments that people raised in the earlier thread. I encourage you to have a read–it’s not a huge thread but a surprising number of people found quixotic and frankly hilarious reasons to be against HTTPS. One person said they saw an instance of the HTTP page being the correct one and the HTTPS version being incorrect. Apparently anecdotes like this are supposed to convince people that HTTPS is untrustworthy 🤷♂️
You suggested that this site should institute a blanket ban on non-https submission links, you got disagreement, and you’re still salty about it.
Let it go. HTTPs has essentially won, in large part thanks to Let’s Encrypt. Great! Take the win, and let the remaining non https content slowly fade away.
I’m really not salty lol. Y’all have this fiction about me in your heads, as if I have some irrational obsession and am gnashing my teeth in fury. I really find this whole thing more funny than anything. I got to see a bunch of really dumb reasons to be anti-HTTPS. One person even claimed that HTTPS is less secure because of issues like Heartbleed. That’s the level of argument of anti-HTTPS people.
Again, we are arguing about a hypothetical here, a suggestion. I’m not coming to take away anyone’s puppy and I had a productive conversation with you earlier about other approaches. I do like the idea of automatically probing for HTTPS support and switching to that if available.
I think Let’s Encrypt has single-handedly made the internet a much safer place these past 10 years
I do like them, but at the same time why do I have to encrypt my recipe site? I would like the option in my browser to not warn about sites that don’t use TLS. Or at least to be presented with an option? Oh, this is a reference recipe site. Would you like not to use encryption? Encryption is such a pita for simple things. I do think that sites that accept credentials always need to be encrypted, but why go through the hassle for things that are public? I am very thankful to let’s encrypt and the caddy web server for making certificates. A non-issue, but at the same time I kind of get tired of oh no it’s not encrypted properly warnings which everyone will ignore anyway.
Because your viewers don’t want their ISP to serve them ads in the content.
Back in ~2012 users of our startup’s iPhone app complained that it crashed when they were on the London Underground (I think, I may be misremembering the details).
It turned out the WiFi down there was modifying HTML pages served over HTTP, and our app loaded HTML pages that included comments with additional instructions for how the app should treat the retrieved page… and those comments were being stripped out!
We fixed the bug by switching to serving those pages over HTTPS instead. I’ve used HTTPS for everything I’ve built since then.
I can sort of understand that since bandwidth was a premium in 2012, so if they could remove as many bytes from the payload as possible, then they increase their network bandwidth overall. Still surprising, but I could at least rationalize it.
Bandwidth was a premium in 2012? That can’t be right, I feel like 2012 had plenty of bandwidth.
No matter how much bandwidth you (an ISP) have, there are always schemes which promise to reduce your usage and thus improve the end-user experience – or invade their experience and make you money.
(Some of those schemes actually work. CDNs, for example.)
Of course, but in 2012 I’m pretty sure even homes could get gigabit networking. I don’t think of it as being a bandwidth constrained time.
I lived in Cleveland at the time (major US city) and was still limited to sub-5 megabit ISP service.
Interesting. I wonder if my memory is just off. NYC had really bad internet back then, as I recall, because our infrastructure is buried and expensive to upgrade. But I could swear we had like 100Mbps.
Dunno. Crazy to think that 2012 was so long ago.
I looked through my inbox to find what speeds I have had over time.
I both understand and resent this. Bad actors are making my life worse, and for some unfathomable reason it’s legal?!
If your ISP is manipulating your data it should be sued into oblivion, in a just world.
It’s not just ISPs, it’s any malicious actor, such as the operator of the wireless access point you’ve connected to (which may not be the person you think it is). You have a choice of either protecting visitors to your site from trivial interception and tampering or leaving them vulnerable. No one is forcing you to choose either way.
Well, it’s not a just world in every country.
I originally chose to not enable TLS for our game’s asset CDN because checking certs on arbitrary Linux distros is ~unsolvable and we have our own manifest signing so we don’t need TLS’s security guarantees anyway, then we found some ISPs with broken caching that would serve the wrong file for a given URL, so I enabled it and disabled cert verification in the Linux client instead.
ISPs don’t even have to be malicious, just crappy…
Why didn’t you just ship your own root certificate? :p
It’s sort of self explanatory. Confidentiality and Integrity.
If you aren’t willing to give those two things to your users I’m really convinced that you just aren’t in a position to host. Recipe site or not, we all have basic obligations. If you can’t meet them, that’s okay, you don’t have to host a website.
https://doesmysiteneedhttps.com/
because IPSEC failed so it’s up to application protocols to provide secure communication instead of the network layer.
Because the some entities are passively monitoring all traffic worldwide.
Other than ad networks?! /s
But then again, those entities only really need metadata.
HTTPS leaks a lot less metadata than HTTP. With HTTP, you can see the full URL of the request. With HTTPS, you can see only the IP address. There’s a huge difference between knowing that I visited Wikipedia and that I read a specific Wikipedia page (the latter may be possible to determine based on the size of the response, but that’s harder). With SNI, the IP address may be shared by hundreds of domains and so a passive adversary doesn’t even see the specific host, let alone the specific page.
Usually SNI is sent in the clear, because the server needs to know the server name to be able to choose the right cert to present to the client, and it would require an extra round trip to do key exchange before certificate exchange.
There’s ongoing work on encrypted SNI (ESNI) but it requires complicated machinery to establish a pre-shared key; it only provides meaningful protection for mass virtual hosters (ugly push to centralize); and it’s of limited benefit without encrypted DNS (another hump on the camel).
Thanks, SNI does not work how I thought it worked. I assumed there was an initial unauthenticated key exchange and then the negotiated key was signed with the cert that the client said it wanted. I believe QUIC works this way, but I might be wrong there as well.
Gosh, I thought QUIC is basically TLS/1.3 with a different transport, but it’s weirder than either of us believed!
TLS/1.3 illustrated shows the SNI in the client hello in the clear
QUIC illustrated shows that the initial packet is encrypted with keys derived from a nonce that is sent in the clear in the initial packet; inside the wrapper is a TLS/1.3 client hello
I suppose this makes sense in that QUIC is designed to always encrypt, and it’s harder to accidentally send a cleartext packet if there aren’t any special cases that need cleartext. RFC 9000 says, “This protection does not provide confidentiality or integrity against attackers that can observe packets, but it does prevent attackers that cannot observe packets from spoofing Initial packets.”
Browsers are application runtimes, and plenty of bad actors are all too happy to include their JS software in your pages
I mean if people are going to ignore the warnings it sounds like you don’t need to enable encryption anyways
This reminds me that Lobsters users are surprisingly vehemently anti-HTTPS: https://lobste.rs/s/zbuc2b/check_for_working_https_before_allowing
That seems an unfair summary of that thread.
A better summary is that lobsters users did not support banning insecure HTTP sites from Lobsters.
I re-read the whole thread and I think it’s fair to say that a lot of the sentiment in the thread (a surprising amount of it) was quite openly anti-HTTPS.
Also I think your terminology is imprecise; I didn’t suggest ‘banning’ HTTP sites from Lobsters, only HTTP link submissions which would benefit from Lobster link juice. I actually said in the thread that users could just post a text submission and then link to it in a comment.
Here are the top scoring submissions with ‘http://’ in the URL since the date of your original discussion. All but 3 redirect to HTTPS. As before, I leave it to the community to decide whether forbidding these sites (because that’s what your original proposal amounted to) or requiring someone to jump through user hostile hoops (possibly triggering spam detection) would be worth it.
As to why someone submits a http link when there’s a https one available, maybe they got it from somewhere else (like HN)?
In summary: there’s a time and place to advocate for https only. Making this site worse to use is not that time nor place.
In that case I think it makes sense to automatically replace http:// with https:// in all submissions and add a comment with the original http:// URL.
I’d accept an addition to the submission which would prompt the submitting user to add https (or add it automatically) if the title fetch check found an alternative. Not gonna code it myself though, life’s too short.
The PR is pretty short :-) https://github.com/lobsters/lobsters/pull/1383
[Comment removed by author]
FWIW, in my experience there’s been a large vein of anti-HTTPS across lobsters outside of that thread. (Not judging, I don’t care other than it wastes comment space when I also don’t care about avoiding HTTPS)
I think it’s safer to say they are against forcing other people to use HTTPS and punishing them and everyone else if they don’t.
I think it’s safe to say that not being able to submit an HTTP-only link to Lobsters is kind of a ‘first-world problem’ as punishments go when modern browsers actually make people jump through hoops to visit HTTP-only sites (as they should, imho)
Regarding your proposal, I stand by the comment I made 2 years ago. But for what it’s worth I am appalled by the disrespect you show here in this thread.
I’m sorry, I don’t know what you are trying to achieve with comments like this, which are completely unproductive and very difficult (for me) to take seriously. It honestly sounds like pearl-clutching like ‘How dare you suggest something that might slightly inconvenience my desire to consume every possible article on the internet!’
This is a strange hill to die on. Yeah, more things should be HTTPS. There’s a bunch of older content that hasn’t been updated either. It’s not something I lose sleep at night over, nor do I think of what others think of that.
Nor do I, I just find it interesting then that so many others get completely riled up about it, as if I’m here to take away their puppy or something. If you look at gerikson’s comment above only a small fraction of the submissions people are interested in, are HTTP only. So as you point out–why lose sleep over making them slightly more inconvenient to submit?
I don’t think this conversation is convincing people to come around to your position.
I think a small minority is loudly against it and most people don’t care. Remember the anti-HTTPS sentiment I mentioned earlier? Fairly sure that’s at least part of it.
I’m not “anti-HTTPS”, but I don’t think there’s much point in limiting submitted links to HTTPS (maybe find the HTTPS version when possible). Again, a lot of older content is out there that hasn’t been updated. It’s a strange hobby horse to get obsessed with and accuse others over though.
Again, I’m not ‘obsessed’ with it or ‘accusing’ anyone of anything. I’ve brought it up twice in the past two years. I don’t know about you, but I don’t call that an obsession. You’re making it sound as if I’m irrationally pointing fingers at people and shouting ‘anti-HTTPS!’, lol. I just summarized some of the arguments that people raised in the earlier thread. I encourage you to have a read–it’s not a huge thread but a surprising number of people found quixotic and frankly hilarious reasons to be against HTTPS. One person said they saw an instance of the HTTP page being the correct one and the HTTPS version being incorrect. Apparently anecdotes like this are supposed to convince people that HTTPS is untrustworthy 🤷♂️
You suggested that this site should institute a blanket ban on non-https submission links, you got disagreement, and you’re still salty about it.
Let it go. HTTPs has essentially won, in large part thanks to Let’s Encrypt. Great! Take the win, and let the remaining non https content slowly fade away.
I’m really not salty lol. Y’all have this fiction about me in your heads, as if I have some irrational obsession and am gnashing my teeth in fury. I really find this whole thing more funny than anything. I got to see a bunch of really dumb reasons to be anti-HTTPS. One person even claimed that HTTPS is less secure because of issues like Heartbleed. That’s the level of argument of anti-HTTPS people.
Again, we are arguing about a hypothetical here, a suggestion. I’m not coming to take away anyone’s puppy and I had a productive conversation with you earlier about other approaches. I do like the idea of automatically probing for HTTPS support and switching to that if available.
I’m removing my reply. Calvin makes a better point than me trying to continue the discussion.
[Comment removed by author]