Is it possible to request a 'Force SSL' option in the User Preferences? January 31, 2016 6:21 PM Subscribe
The EFF offers HTTPS Anywhere, but it's not available for all browser, and fails on some script calls.
As a feature this would be amazing. Thank you!
You are the best. Thank you!
posted by four panels at 6:37 PM on January 31, 2016
posted by four panels at 6:37 PM on January 31, 2016
I wish I knew what this means.
posted by Oyéah at 9:27 PM on January 31, 2016 [3 favorites]
posted by Oyéah at 9:27 PM on January 31, 2016 [3 favorites]
I wish I knew what this means.
The HTTPS protocol gets you a secure, encrypted connection with a particular website that, as a general rule means that what messages you are sending that website can’t be parsed (though a watcher could still know that you were connecting to that particular site). You are probably most familiar with HTTPS as what your bank / Amazon is using to keep people from prying on your credit card transactions and stealing your info.
For various reasons, people are more & more interested in keeping all of their communications with websites encrypted. The EFF offers a browser add-on called HTTPS Everywhere that will try to default switch you over to HTTPS when talking with any given website that supports the protocol. It can be kind of janky, though, so it’s nice if a website will just give you the option to force the default to be HTTPS itself.
posted by Going To Maine at 10:06 PM on January 31, 2016 [5 favorites]
The HTTPS protocol gets you a secure, encrypted connection with a particular website that, as a general rule means that what messages you are sending that website can’t be parsed (though a watcher could still know that you were connecting to that particular site). You are probably most familiar with HTTPS as what your bank / Amazon is using to keep people from prying on your credit card transactions and stealing your info.
For various reasons, people are more & more interested in keeping all of their communications with websites encrypted. The EFF offers a browser add-on called HTTPS Everywhere that will try to default switch you over to HTTPS when talking with any given website that supports the protocol. It can be kind of janky, though, so it’s nice if a website will just give you the option to force the default to be HTTPS itself.
posted by Going To Maine at 10:06 PM on January 31, 2016 [5 favorites]
Is there any reason NOT to do this?
posted by anotherpanacea at 5:14 AM on February 1, 2016 [1 favorite]
posted by anotherpanacea at 5:14 AM on February 1, 2016 [1 favorite]
not really.
posted by andrewcooke at 5:25 AM on February 1, 2016
posted by andrewcooke at 5:25 AM on February 1, 2016
pb, what's your current thinking on moving to https-by-default at some point, with maybe an option to turn it off instead of on? (Or is the option even necessary?)
As context for others, the general trend in the last few years has been for sites to encrypt all their traffic. Twitter, Facebook, and Wikimedia, for example, moved to an encrypt-by-default account setting a few years ago. US government websites are required to provide only encrypted versions by the end of 2016. Google has started using https support as a ranking signal, and Mozilla is talking about gradually phasing out non-secure http from Firefox. It's clear that we're headed for an all-encrypted web, which is a good thing -- I'm just not sure what (if any) issues there are for a site like Metafilter to make the jump.
posted by jhc at 6:21 AM on February 1, 2016 [1 favorite]
As context for others, the general trend in the last few years has been for sites to encrypt all their traffic. Twitter, Facebook, and Wikimedia, for example, moved to an encrypt-by-default account setting a few years ago. US government websites are required to provide only encrypted versions by the end of 2016. Google has started using https support as a ranking signal, and Mozilla is talking about gradually phasing out non-secure http from Firefox. It's clear that we're headed for an all-encrypted web, which is a good thing -- I'm just not sure what (if any) issues there are for a site like Metafilter to make the jump.
posted by jhc at 6:21 AM on February 1, 2016 [1 favorite]
Awesome. Turned it on!
posted by cjorgensen at 6:35 AM on February 1, 2016
posted by cjorgensen at 6:35 AM on February 1, 2016
I wish I knew what this means.
The idea is that by browsing a web site via an https:// address it will prevent your internet service provider, the web site's internet service provider and/or web host, a café or hotel wireless network you're connected through and the other people on that network, and anyone else between your computer or device and the web site's computer from being able to read the traffic and hence tell which particular web pages you're viewing and what you type in searches for, and for example keep those people from seeing what your MeFi user name is at the top of the web pages being sent to you. They can still see which computer on the internet you're contacting, so if there's only one web site running on that computer they'd know which web site you're looking at, just not which particular pages.
The web site itself that you're viewing still knows which particular pages you're viewing and records that information and might sell it, and may also put tracking scripts into its pages that send the same information to third parties like Google or Facebook or hundreds of other companies. Ad blocking software usually tries to block tracking scripts along with the ads if you're running that.
Also, a computer virus or other malware that has infected your computer can probably watch everything you do. And encrypted traffic could theoretically be recorded now and decrypted at some point in the future when computers are more powerful, and the NSA and other such groups may be able to decrypt traffic even now.
I use both ad blocking software (uBlock Origin and a more complicated tool called uMatrix that complements it and was created by the same guy) and try to view web sites through https:// addresses whenever possible. There are more sophisticated ways of trying to protect yourself as well if you expect you may be targeted by a government or something like that.
posted by XMLicious at 6:37 AM on February 1, 2016 [2 favorites]
Last time we talked about it, I think the main issue with going to HTTPS by default is that some external shit over which we have no control consequently breaks. Some variety of failure to gracefully handle outbound links from one or another common site, or bad interactions with some common scripts/extensions, etc. And defaulting to "some shit is definitely gonna break" isn't the best user experience decision to make, even if we're making it for otherwise laudable reasons.
That said, that may be old news at this point—whatever used to break may be up to speed now—in which case it's something we could certainly revisit as a possibility. If it doesn't have a negative impact on user's experience on MeFi or off and doesn't present significant server overhead costs, there's nothing wrong with the idea in its own right, but those both have to definitively stop being "if"s.
posted by cortex (staff) at 7:08 AM on February 1, 2016
That said, that may be old news at this point—whatever used to break may be up to speed now—in which case it's something we could certainly revisit as a possibility. If it doesn't have a negative impact on user's experience on MeFi or off and doesn't present significant server overhead costs, there's nothing wrong with the idea in its own right, but those both have to definitively stop being "if"s.
posted by cortex (staff) at 7:08 AM on February 1, 2016
It's clear that we're headed for an all-encrypted web, which is a good thing -- I'm just not sure what (if any) issues there are for a site like Metafilter to make the jump.
This is good for security, but for developers in general, especially novice developers, getting a certificate costs money right now, and configuring SSL for your web server can be difficult depending on what you are working with.
I think it is a good idea to encourage commercial sites and anything dealing with sensitive data. However, I'm not sure it's being done in a way that creates yet another barrier to entry for people that just want to get involved with doing things on the web. I think it should be increasingly cheap and easy to make yourself a web service, rather than inching toward a complicated gatekept process for professionals.
It kind of reminds me of eliminating boring jobs. Sure, we should eliminate them, but only after we make sure people can survive without them.
To that end, there is an effort (Let's Encrypt) to provide free certs. However, I'm not sure how they're solving the fundamental problem with certification. The idea behind a certificate is that someone has checked you out and finds you to be legit (not a "bad guy" and deserving of the little green icon in your browser's location bar). This is going to have involve humans checking things out. If we go to an https-only web, how are they going to process that many applications for certificates?
It looks like a root problem here is tying legitimacy to encryption. We want to stop snooping and man-in-the-middle attacks on http requests. So, we encrypt. However, we don't allow encrypting unless we're sure you are good as judged by humans. I think it'd be great if we could divorce these things. Just allow https with certs that don't necessarily guarantee you're a trusted source – just ensure that no one is eavesdropping on communications with that source. That'd go a long way. Then, do something else to let people know a source is good.
posted by ignignokt at 7:49 AM on February 1, 2016 [1 favorite]
This is good for security, but for developers in general, especially novice developers, getting a certificate costs money right now, and configuring SSL for your web server can be difficult depending on what you are working with.
I think it is a good idea to encourage commercial sites and anything dealing with sensitive data. However, I'm not sure it's being done in a way that creates yet another barrier to entry for people that just want to get involved with doing things on the web. I think it should be increasingly cheap and easy to make yourself a web service, rather than inching toward a complicated gatekept process for professionals.
It kind of reminds me of eliminating boring jobs. Sure, we should eliminate them, but only after we make sure people can survive without them.
To that end, there is an effort (Let's Encrypt) to provide free certs. However, I'm not sure how they're solving the fundamental problem with certification. The idea behind a certificate is that someone has checked you out and finds you to be legit (not a "bad guy" and deserving of the little green icon in your browser's location bar). This is going to have involve humans checking things out. If we go to an https-only web, how are they going to process that many applications for certificates?
It looks like a root problem here is tying legitimacy to encryption. We want to stop snooping and man-in-the-middle attacks on http requests. So, we encrypt. However, we don't allow encrypting unless we're sure you are good as judged by humans. I think it'd be great if we could divorce these things. Just allow https with certs that don't necessarily guarantee you're a trusted source – just ensure that no one is eavesdropping on communications with that source. That'd go a long way. Then, do something else to let people know a source is good.
posted by ignignokt at 7:49 AM on February 1, 2016 [1 favorite]
getting a certificate costs money right now, and configuring SSL for your web server can be difficult depending on what you are working with.
The EFF are also trying to help people with this with their Let's Encrypt project as ignignokt says but I tried to parse it and could really get nowhere and I'm moderately tech savvy. I feel like as more and more people are placing content on the web using CMSes, those CMSes can start the process. There are WordPress plugins that will help people do this with their own blog, for example.
We went to https at the Internet Archive last year and there was a lot of fiddling to make sure stuff didn't break and we were finding little edge cases for months afterwards. Things that link to other things, display things inline, etc. I'm definitely in favor of this, but appreciate the caution.
posted by jessamyn (retired) at 8:04 AM on February 1, 2016 [1 favorite]
The EFF are also trying to help people with this with their Let's Encrypt project as ignignokt says but I tried to parse it and could really get nowhere and I'm moderately tech savvy. I feel like as more and more people are placing content on the web using CMSes, those CMSes can start the process. There are WordPress plugins that will help people do this with their own blog, for example.
We went to https at the Internet Archive last year and there was a lot of fiddling to make sure stuff didn't break and we were finding little edge cases for months afterwards. Things that link to other things, display things inline, etc. I'm definitely in favor of this, but appreciate the caution.
posted by jessamyn (retired) at 8:04 AM on February 1, 2016 [1 favorite]
Just allow https with certs that don't necessarily guarantee you're a trusted source – just ensure that no one is eavesdropping on communications with that source. That'd go a long way. Then, do something else to let people know a source is good.
Extended Validation certificates do this to an extent.
posted by jedicus at 8:30 AM on February 1, 2016
Extended Validation certificates do this to an extent.
posted by jedicus at 8:30 AM on February 1, 2016
To that end, there is an effort (Let's Encrypt) to provide free certs. However, I'm not sure how they're solving the fundamental problem with certification.
Metafilter (and the vast majority of sites) use "domain validation" instead of "extended validation." In order to get a domain-validated certificate, all you have to do is prove that you control the domain registration for metafilter.com -- something that can be confirmed automatically without a human in the loop.
(This is why if you go to bankofamerica.com in Firefox, you see "Bank of America Corporation (US)" in the address bar -- they've actually paid for human verification that your browser is talking to a particular legal entity. But you don't see that for Metafilter or most sites.)
Up to now, domain-validated certificates have been way too expensive and technically complicated for what they are. Let's Encrypt offers this kind of certificate for free, and provides APIs and tools to make it easy for a sysadmin or software tool to automatically generate. Jessamyn's right that it's still a bit complicated if you're not a sysadmin -- but it'll have a big impact once it starts being built into other tools.
posted by jhc at 8:40 AM on February 1, 2016 [2 favorites]
Metafilter (and the vast majority of sites) use "domain validation" instead of "extended validation." In order to get a domain-validated certificate, all you have to do is prove that you control the domain registration for metafilter.com -- something that can be confirmed automatically without a human in the loop.
(This is why if you go to bankofamerica.com in Firefox, you see "Bank of America Corporation (US)" in the address bar -- they've actually paid for human verification that your browser is talking to a particular legal entity. But you don't see that for Metafilter or most sites.)
Up to now, domain-validated certificates have been way too expensive and technically complicated for what they are. Let's Encrypt offers this kind of certificate for free, and provides APIs and tools to make it easy for a sysadmin or software tool to automatically generate. Jessamyn's right that it's still a bit complicated if you're not a sysadmin -- but it'll have a big impact once it starts being built into other tools.
posted by jhc at 8:40 AM on February 1, 2016 [2 favorites]
whatever used to break may be up to speed now
The only thing I am aware of that still breaks with encryption on is embedding Flickr photos in profile.
The EFF are also trying to help people with this with their Let's Encrypt project
So happy Dreamhost added this to their features. Easy to set up and automatically renews.
posted by terrapin at 8:54 AM on February 1, 2016
The only thing I am aware of that still breaks with encryption on is embedding Flickr photos in profile.
The EFF are also trying to help people with this with their Let's Encrypt project
So happy Dreamhost added this to their features. Easy to set up and automatically renews.
posted by terrapin at 8:54 AM on February 1, 2016
The only thing I am aware of that still breaks with encryption on is embedding Flickr photos in profile.
Yeah, the only profile widget that works with a secure connection is Twitter. Many mefi-specific Greasemonkey scripts don't work when you have secure browsing enabled.
posted by pb (staff) at 9:11 AM on February 1, 2016
Yeah, the only profile widget that works with a secure connection is Twitter. Many mefi-specific Greasemonkey scripts don't work when you have secure browsing enabled.
posted by pb (staff) at 9:11 AM on February 1, 2016
Yeah, the greasemonkey script thing has been an issue and probably hasn't magically resolved itself since we last looked—for a lot of users who use those and aren't particularly concerned about SSL, breaking all that for no apparent reason isn't much of a sales pitch.
Which, a big "hey let's revisit and review and organize and update MeFi-related greasemonkey scripts" party at some point wouldn't be a terrible idea and might help mitigate that if we were to make a move like this, though there's no guarantee that any given script author would be aware or available for that so it'd likely still be a bumpy ride at best. Ad hoc community-sourced patches for such stuff could see people through but depending on how any given absent script author has licensed their code that could be a little thorny in its own right.
posted by cortex (staff) at 9:15 AM on February 1, 2016 [1 favorite]
Which, a big "hey let's revisit and review and organize and update MeFi-related greasemonkey scripts" party at some point wouldn't be a terrible idea and might help mitigate that if we were to make a move like this, though there's no guarantee that any given script author would be aware or available for that so it'd likely still be a bumpy ride at best. Ad hoc community-sourced patches for such stuff could see people through but depending on how any given absent script author has licensed their code that could be a little thorny in its own right.
posted by cortex (staff) at 9:15 AM on February 1, 2016 [1 favorite]
Hmm, yeah. It does look like many of the greasemonkey scripts in the wiki are missing the "@include https://*.metafilter.com" at the top that would make them work with SSL. (Although since secure browsing has been available for a couple of years now, and predates the modern theme, I would hope that the more frequently-used ones have been updated?)
I get that this may not be worth the tradeoff right now. Just to play it out a bit, the way I would put the sales pitch is something like:
posted by jhc at 12:03 PM on February 1, 2016 [1 favorite]
I get that this may not be worth the tradeoff right now. Just to play it out a bit, the way I would put the sales pitch is something like:
(1) Secure browsing is now on by default! Your fellow Mefites (and visitors searching for answers to personal problems) are now a bit safer from being snooped on or impersonated by their roommates/coffee shop patrons/officemates/ISPs/governments.The widget thing is tricky. If you were otherwise enthusiastic about this, there are ways you could work around it to keep most or all of them working -- for example, the Flickr widget could be fixed by adding a few lines of JS to the widget block to rewrite the <img> tags, since the actual script and images are available on https. If all else failed you could have a serverside view to cache and replay the widget securely. But that's a fiddly path to go down if it's not a priority.
(2) This will deactivate some older greasemonkey scripts. If you rely on one of those scripts, you can turn off secure browsing in [your preferences], or visit [metafilter.com/http] to opt out for a particular browser. And drop a note in this thread to let people know that you're hoping to get that script working. If you're a greasemonkey script author, instructions for updating a script are [here].
posted by jhc at 12:03 PM on February 1, 2016 [1 favorite]
Google has started using https support as a ranking signal
And they're tightening the screws. My tech trends crystal ball doesn't work all that well, but I wouldn't be surprised if Google AdSense starts requiring that sites be HTTPS-only sooner rather than later.
posted by metaquarry at 1:08 PM on February 1, 2016
And they're tightening the screws. My tech trends crystal ball doesn't work all that well, but I wouldn't be surprised if Google AdSense starts requiring that sites be HTTPS-only sooner rather than later.
posted by metaquarry at 1:08 PM on February 1, 2016
...the actual script and images are available on https.
That's good news. Last time I looked they didn't offer the script over https. I just updated things so the Flickr widgets show up for folks with secure browsing on. Thanks for the heads up.
posted by pb (staff) at 1:27 PM on February 1, 2016 [1 favorite]
That's good news. Last time I looked they didn't offer the script over https. I just updated things so the Flickr widgets show up for folks with secure browsing on. Thanks for the heads up.
posted by pb (staff) at 1:27 PM on February 1, 2016 [1 favorite]
fwiw, let's encrypt is not so easy if you're running on a shared host.
posted by andrewcooke at 2:57 PM on February 1, 2016
posted by andrewcooke at 2:57 PM on February 1, 2016
Let's Encrypt is actually super easy.
I'm on a shared host, a number of different shared hosts, and it's actually not trivial to get it working.
posted by jessamyn (retired) at 4:52 PM on February 1, 2016 [1 favorite]
I'm on a shared host, a number of different shared hosts, and it's actually not trivial to get it working.
posted by jessamyn (retired) at 4:52 PM on February 1, 2016 [1 favorite]
"Let's Encrypt is actually super easy. The only downside right now is that the certs expire in a short amount of time. When I used it last, I ran a single shell script and answered a few questions. It automatically did everything else, which was awesome. Once it's out of beta the expiration time will be much longer, and at that point there are very few hurdles for developers to use HTTPS all the time."
Once it's out of beta, the expiration time will drop to an even shorter amount since one of their goals is to fully automate the certificate process thus ensuring that if the private key ever leaks the amount of time it'll be active for would be a short time and since the renewal mechanism would be automated there would be no noticeable downtime.
posted by I-baLL at 4:57 PM on February 1, 2016
Once it's out of beta, the expiration time will drop to an even shorter amount since one of their goals is to fully automate the certificate process thus ensuring that if the private key ever leaks the amount of time it'll be active for would be a short time and since the renewal mechanism would be automated there would be no noticeable downtime.
posted by I-baLL at 4:57 PM on February 1, 2016
One more vote for the "https-by-default is a good idea and probably necessary soonish" side of this question. I know about the class of things that will make the transition irritating, but between the general (terrible) security climate, search rankings, and upcoming client changes, it's probably worth thinking of as a priority.
Re: Let's Encrypt, it does seem to be working pretty well in mechanical terms right now, but there are still rough edges and features not finished. And yeah, I'm going to guess that most shared hosting providers are going to have to do specific work around it, but at least players like DreamHost are working on it.
(There's a series of relatively straightforward tutorial docs from a couple of my co-workers that might be helpful if you're managing your own boxen and interested in giving LE a look. It might make good sense to hold off 'til it's out of beta, but I have reasonably high hopes for it at this point.)
posted by brennen at 5:48 PM on February 1, 2016
Re: Let's Encrypt, it does seem to be working pretty well in mechanical terms right now, but there are still rough edges and features not finished. And yeah, I'm going to guess that most shared hosting providers are going to have to do specific work around it, but at least players like DreamHost are working on it.
(There's a series of relatively straightforward tutorial docs from a couple of my co-workers that might be helpful if you're managing your own boxen and interested in giving LE a look. It might make good sense to hold off 'til it's out of beta, but I have reasonably high hopes for it at this point.)
posted by brennen at 5:48 PM on February 1, 2016
Thanks for the quick fix on the Flickr widget, pb!
If I'm doing this right, the Vimeo widget also seems to work on SSL now.
posted by jhc at 6:10 PM on February 1, 2016
If I'm doing this right, the Vimeo widget also seems to work on SSL now.
posted by jhc at 6:10 PM on February 1, 2016
... and it also looks like the LibraryThing and This Is My Jam widgets now support SSL.
posted by jhc at 6:24 PM on February 1, 2016
posted by jhc at 6:24 PM on February 1, 2016
Thanks jhc, I'll check those out. In the past some of those services have served secure versions of their widget scripts but then insecure assets within. So I'll need to double-check that those are indeed serving up secure versions.
posted by pb (staff) at 7:45 PM on February 1, 2016
posted by pb (staff) at 7:45 PM on February 1, 2016
And sadly, TIMJ is no more so we can probably remove the widget option at least.
posted by pb (staff) at 7:47 PM on February 1, 2016 [1 favorite]
posted by pb (staff) at 7:47 PM on February 1, 2016 [1 favorite]
I think it'd be great if we could divorce these things. Just allow https with certs that don't necessarily guarantee you're a trusted source – just ensure that no one is eavesdropping on communications with that source. That'd go a long way. Then, do something else to let people know a source is good.
The entire point of HTTPS is to provide some kind of guarantee that you're having a private conversation with the service you're using it to connect to. A protocol that doesn't validate the server you're connecting to would give you no way to be sure that you're not connecting to a man-in-the-middle relay attacker.
posted by flabdablet at 4:25 AM on February 2, 2016 [1 favorite]
The entire point of HTTPS is to provide some kind of guarantee that you're having a private conversation with the service you're using it to connect to. A protocol that doesn't validate the server you're connecting to would give you no way to be sure that you're not connecting to a man-in-the-middle relay attacker.
posted by flabdablet at 4:25 AM on February 2, 2016 [1 favorite]
I think ignignokt's point is that it would better if you could just press a button on your web browser to switch to an encrypted connection to any given host, or flip a switch on your web server so that it only accepts encrypted connections, rather than have the process of doing that being necessarily tied up in or dependent upon the identity of the holder of encryption keys supposedly having been verified by a supposedly-trustworthy certificate authority which your browser/client/OS vendor has deigned to include root certificates for.
There's such a broad spectrum of degrees of understanding of what's going on among end users that it's long past the time when it makes sense to separate those concerns, even if it actually made sense back in the nineteen hundreds whenever the initial RFC drafts on SSL were written. If your internet-of-crap toaster may be providing information and even serving web pages over the network there's no point in having a security infrastructure that prevents encrypted connections until the infrastructure pretends it has actually certified the legitimate identity of your toaster, because it hasn't.
posted by XMLicious at 5:04 AM on February 2, 2016 [2 favorites]
There's such a broad spectrum of degrees of understanding of what's going on among end users that it's long past the time when it makes sense to separate those concerns, even if it actually made sense back in the nineteen hundreds whenever the initial RFC drafts on SSL were written. If your internet-of-crap toaster may be providing information and even serving web pages over the network there's no point in having a security infrastructure that prevents encrypted connections until the infrastructure pretends it has actually certified the legitimate identity of your toaster, because it hasn't.
posted by XMLicious at 5:04 AM on February 2, 2016 [2 favorites]
Thanks pb for fixing the Flickr badge in https!
I fixed my Flickr username, and whilst the badge displays the images in the badge are not. I checked my flickr settings and I don't have any private/hidden settings enabled. So I went to the social explorer page for mefites with Flickr accounts, and clicked on a few user names randomly. None of the images in the user's badges showed for me in Safari or Firefox (OS X), but they do in Chrome.
Any idea what settings in Safari *and* Firefox would keep me from viewing the Flickr badge images? I don't use Chrome often so I assume I have made some changes in the other 2 browsers, but nothing is jumping out at me as obvious. Thanks.
posted by terrapin at 7:01 AM on February 2, 2016
I fixed my Flickr username, and whilst the badge displays the images in the badge are not. I checked my flickr settings and I don't have any private/hidden settings enabled. So I went to the social explorer page for mefites with Flickr accounts, and clicked on a few user names randomly. None of the images in the user's badges showed for me in Safari or Firefox (OS X), but they do in Chrome.
Any idea what settings in Safari *and* Firefox would keep me from viewing the Flickr badge images? I don't use Chrome often so I assume I have made some changes in the other 2 browsers, but nothing is jumping out at me as obvious. Thanks.
posted by terrapin at 7:01 AM on February 2, 2016
Firefox and Safari are both testing fine for me. My first guess is that you might have a browser add-on blocking things for you? Maybe a privacy plugin like Ghostery or AdBlock?
posted by pb (staff) at 7:53 AM on February 2, 2016
posted by pb (staff) at 7:53 AM on February 2, 2016
I THOUGHT I had whitelisted MeFi. But apparently not on my laptop. Thanks!
posted by terrapin at 7:59 AM on February 2, 2016 [1 favorite]
posted by terrapin at 7:59 AM on February 2, 2016 [1 favorite]
That said, that may be old news at this point—whatever used to break may be up to speed now
I have just the last six months been dealing with a client trying to go https all the time and the one continued source of pain is ad networks and they continue to suck in amazingly frustrating ways to troubleshoot. Since they often load different js junk and then those things load junk and it seems like they do absolutely no policing of the technical quality of the content... yeah we had a lot of stuff be recurring AND intermittent pains in the ass.
The ads on MF are way less garbage than the bazillion bunches of garbage this client uses so I doubt it's a problem and I suspect for a lot of users the fact that ads won't load right isn't really something they would worry about anyway (except perhaps when it cascades into making other parts of the page janky looking), but I thought I'd share my fresher "has everyone gotten their shit together" data point.
posted by phearlez at 9:06 AM on February 2, 2016
I have just the last six months been dealing with a client trying to go https all the time and the one continued source of pain is ad networks and they continue to suck in amazingly frustrating ways to troubleshoot. Since they often load different js junk and then those things load junk and it seems like they do absolutely no policing of the technical quality of the content... yeah we had a lot of stuff be recurring AND intermittent pains in the ass.
The ads on MF are way less garbage than the bazillion bunches of garbage this client uses so I doubt it's a problem and I suspect for a lot of users the fact that ads won't load right isn't really something they would worry about anyway (except perhaps when it cascades into making other parts of the page janky looking), but I thought I'd share my fresher "has everyone gotten their shit together" data point.
posted by phearlez at 9:06 AM on February 2, 2016
I tested out the Vimeo widget in secure browsing and it checked out. So that's back for secure profile pages. LibraryThing serves mixed content so that's still a no-go. And I removed the This is My Jam widget since no one will have new music there. (The service is still listed in the Also On section.)
posted by pb (staff) at 2:08 PM on February 2, 2016
posted by pb (staff) at 2:08 PM on February 2, 2016
Thanks for taking a look. Are you sure the LibraryThing widget doesn't work? Their widget config page is itself available over https and embeds the widget, which seems to load everything over https. If it's an issue with a particular widget config, you could toss them a bug report?
(Also, as long as I'm being annoying -- looks like the last.fm widget that was busted in 2011 is still showing on profile pages (and is still busted)?)
posted by jhc at 5:30 PM on February 2, 2016
(Also, as long as I'm being annoying -- looks like the last.fm widget that was busted in 2011 is still showing on profile pages (and is still busted)?)
posted by jhc at 5:30 PM on February 2, 2016
Yep, positive on the LibraryThing widget. It breaks the encryption lock by loading insecure images.
Thanks, I'll take a look at the last.fm widget.
posted by pb (staff) at 8:05 PM on February 2, 2016
Thanks, I'll take a look at the last.fm widget.
posted by pb (staff) at 8:05 PM on February 2, 2016
Yeah, looks like last.fm completely discontinued their widget service. I removed it as an option.
I remember watching the forums in 2011 during that outage. It did come back for a while, but I'm not sure when the plug was finally pulled.
posted by pb (staff) at 8:22 PM on February 2, 2016
I remember watching the forums in 2011 during that outage. It did come back for a while, but I'm not sure when the plug was finally pulled.
posted by pb (staff) at 8:22 PM on February 2, 2016
it would better if you could just press a button on your web browser to switch to an encrypted connection to any given host, or flip a switch on your web server so that it only accepts encrypted connections, rather than have the process of doing that being necessarily tied up in or dependent upon the identity of the holder of encryption keys supposedly having been verified by a supposedly-trustworthy certificate authority which your browser/client/OS vendor has deigned to include root certificates for.
The trouble with that view is that you can't simply handwave the identity issue into nonexistence.
The sole point of an encrypted connection is to make the content of traffic transiting parts of the network beyond your control inaccessible to any potential interceptor. If it doesn't actually achieve that purpose, it isn't worth its extra complexity.
If you've got encryption turned on at your end, but have no idea who the other end of your encrypted connection really is, then the point of encryption is completely lost - because you might actually be running an encrypted connection between your end and your friendly local NSA intercept box, which is then relaying all your traffic to the server you thought you were talking to.
In fact this pattern is already quite disturbingly common. It's typically not actually the NSA running the man-in-the-middle attack, but a corporate content-inspection firewall appliance or a local advertising trojan. These all rely on bogus root certificates installed in your client device that allows the interceptor to spoof the far end's genuine SSL certificate; the net effect is to implement the exact separation between encryption and far-end identity verification that you're advocating.
posted by flabdablet at 5:58 PM on February 3, 2016
The trouble with that view is that you can't simply handwave the identity issue into nonexistence.
The sole point of an encrypted connection is to make the content of traffic transiting parts of the network beyond your control inaccessible to any potential interceptor. If it doesn't actually achieve that purpose, it isn't worth its extra complexity.
If you've got encryption turned on at your end, but have no idea who the other end of your encrypted connection really is, then the point of encryption is completely lost - because you might actually be running an encrypted connection between your end and your friendly local NSA intercept box, which is then relaying all your traffic to the server you thought you were talking to.
In fact this pattern is already quite disturbingly common. It's typically not actually the NSA running the man-in-the-middle attack, but a corporate content-inspection firewall appliance or a local advertising trojan. These all rely on bogus root certificates installed in your client device that allows the interceptor to spoof the far end's genuine SSL certificate; the net effect is to implement the exact separation between encryption and far-end identity verification that you're advocating.
posted by flabdablet at 5:58 PM on February 3, 2016
...Okay so why is it again that ignignokt or anyone else should be forced to pay money simply to turn on encryption and in return for a "certification" from a system that will also hand out the certificates you're referring to as "bogus"? That's the whole reason I was emphasizing that identity is only supposedly being verified through charging for certificates.
If verifying identity with certainty and kinda-sorta verifying identity, but who the hell knows, are two valid gradations of security measures in your book then encryption alone with a free out-of-band route for distributing public keys—which users are made to understand the significance of through their UI—is a third one. (The latter two being considerably less valuable security measures than the first one of course.)
posted by XMLicious at 9:57 PM on February 3, 2016
If verifying identity with certainty and kinda-sorta verifying identity, but who the hell knows, are two valid gradations of security measures in your book then encryption alone with a free out-of-band route for distributing public keys—which users are made to understand the significance of through their UI—is a third one. (The latter two being considerably less valuable security measures than the first one of course.)
posted by XMLicious at 9:57 PM on February 3, 2016
Or, by "bogus" certificates, are you describing a situation where an attacker essentially has complete control over a user's device, for example because they're able to get the device manufacturer to pre-install malware in the case of Superfish? Because of course that will permit MITM attacks or just about anything else, and it has nothing to do with the design of the system, so this is no argument in favor of making people pay for certificates regardless of what they're doing and eliding the distinction between encryption and identity to users.
posted by XMLicious at 10:30 PM on February 3, 2016
posted by XMLicious at 10:30 PM on February 3, 2016
encryption alone with a free out-of-band route for distributing public keys—which users are made to understand the significance of through their UI—is a third one.
SSL already supports that model; self-signed keys exist. Unfortunately, handwaving a "free out-of-band route for distributing public keys" into existence doesn't really work either, because most users never will understand the significance of anything security-related even after hours and hours of one-on-one personal training.
posted by flabdablet at 10:11 AM on February 4, 2016
SSL already supports that model; self-signed keys exist. Unfortunately, handwaving a "free out-of-band route for distributing public keys" into existence doesn't really work either, because most users never will understand the significance of anything security-related even after hours and hours of one-on-one personal training.
posted by flabdablet at 10:11 AM on February 4, 2016
Yeah so a free route for distributing public keys is called a key server by the way, no handwaving necessary, but God forbid you miss an opportunity to use your favorite word again. I'm glad that after all the righteous avowal of impossibility and pointlessness you realized you already knew what a self-signed key was, though.
posted by XMLicious at 12:36 PM on February 4, 2016
posted by XMLicious at 12:36 PM on February 4, 2016
a free route for distributing public keys is called a key server by the way
And in order to trust the keys you obtain from a key server, you need to trust the key server. So once you scale key servers to the point where the general public can use them without needing to understand them, they end up costing something to maintain and looking an awful lot like the existing SSL PKI.
posted by flabdablet at 10:51 AM on February 5, 2016
And in order to trust the keys you obtain from a key server, you need to trust the key server. So once you scale key servers to the point where the general public can use them without needing to understand them, they end up costing something to maintain and looking an awful lot like the existing SSL PKI.
posted by flabdablet at 10:51 AM on February 5, 2016
I'm glad that after all the righteous avowal of impossibility and pointlessness
I'm not saying, and certainly don't mean, that encryption methods that don't rely on identity verification ultimately delegated to generally trusted certification authorities are impossible or pointless.
I am saying that encrypting data without some prior assurance of the identity of the intended decryptor(s) is pointless; it's security theatre, not security. You can implement that assurance any way you like, but it has to be done some way; simply turning on encryption without paying any attention at all to the identity verification issue is a complete waste of time.
posted by flabdablet at 10:57 AM on February 5, 2016
I'm not saying, and certainly don't mean, that encryption methods that don't rely on identity verification ultimately delegated to generally trusted certification authorities are impossible or pointless.
I am saying that encrypting data without some prior assurance of the identity of the intended decryptor(s) is pointless; it's security theatre, not security. You can implement that assurance any way you like, but it has to be done some way; simply turning on encryption without paying any attention at all to the identity verification issue is a complete waste of time.
posted by flabdablet at 10:57 AM on February 5, 2016
I don't really agree that it's pointless; it doesn't do much to foil any kind of serious attack like you say, but it'll stop casual eavesdroppers on the same network and generally raises the work any random attacker needs to do by just a bit. Like the $5 entry barrier, speedbumps matter, even if they're not ~security~ or whatever.
Is that worth it? You can reasonably argue that it's not, but it's not fair to say it's a pointless complete waste of time.
posted by vibratory manner of working at 5:14 AM on February 6, 2016
Is that worth it? You can reasonably argue that it's not, but it's not fair to say it's a pointless complete waste of time.
posted by vibratory manner of working at 5:14 AM on February 6, 2016
it'll stop casual eavesdroppers on the same network
...at least until the casual eavesdroppers get access to the fully automated no-brainer MITM tools that poor security design allows for the creation of, which will make casual eavesdropping every bit as easy as it used to be before the protocol complexity spiral got ratcheted around by one more turn.
It wasn't that long ago that randomized session cookies were thought to offer sufficient protection against interference from attackers on the same LAN. After all, it takes a lot of fooling about to spoof somebody else's session cookies, and the kind of script kiddie that hangs around in an Internet cafe with malicious intent doesn't have the skills for that, right? And then somebody published Firesheep.
If the underlying security architecture is fundamentally broken, then all it takes to exploit it is software designed to do so, and as soon as there's a use for such software it will appear and will become easily available to anybody who wants its capabilities.
There is no point at all in engineering a protocol-complexity arms race between people who want privacy and people who want to invade privacy. Encryption without decryptor identity verification amounts to an attempt at security-by-obscurity. It's insecure by design, and it would be exploited as soon as its use became widespread enough to matter.
posted by flabdablet at 7:18 AM on February 6, 2016
...at least until the casual eavesdroppers get access to the fully automated no-brainer MITM tools that poor security design allows for the creation of, which will make casual eavesdropping every bit as easy as it used to be before the protocol complexity spiral got ratcheted around by one more turn.
It wasn't that long ago that randomized session cookies were thought to offer sufficient protection against interference from attackers on the same LAN. After all, it takes a lot of fooling about to spoof somebody else's session cookies, and the kind of script kiddie that hangs around in an Internet cafe with malicious intent doesn't have the skills for that, right? And then somebody published Firesheep.
If the underlying security architecture is fundamentally broken, then all it takes to exploit it is software designed to do so, and as soon as there's a use for such software it will appear and will become easily available to anybody who wants its capabilities.
There is no point at all in engineering a protocol-complexity arms race between people who want privacy and people who want to invade privacy. Encryption without decryptor identity verification amounts to an attempt at security-by-obscurity. It's insecure by design, and it would be exploited as soon as its use became widespread enough to matter.
posted by flabdablet at 7:18 AM on February 6, 2016
You are not logged in, either login or create an account to post comments
posted by pb (staff) at 6:22 PM on January 31, 2016 [15 favorites]