Weekly Edition
Return to the Front pageRecent Features
| |||||||||||||
New LWN feature: HTTPS-only access
We would like to announce a new LWN feature that readers may find useful: forcing HTTPS (i.e. SSL/TLS) connections for every page in the site. Enabling the feature will help prevent man-in-the-middle eavesdropping and session hijacking. If you want to give it a try, go to the "My Account" page, then to "Customize your account", and the "Force SSL" option is the first listed. You will have to log out and log back in for it take effect and, because of Google ads, you may get a browser popup complaining about insecure content the first time you access the site. If you run into any problems with the new feature, please let us know at lwn@lwn.net.
(Log in to post comments)
New LWN feature: HTTPS-only access Posted Feb 17, 2011 23:23 UTC (Thu) by cyd (guest, #4153) [Link]
Tin Foil Hat Mode Turn On!
New LWN feature: HTTPS-only access Posted Feb 17, 2011 23:57 UTC (Thu) by abartlet (subscriber, #3928) [Link]
I prefer to think of it as 'conference network protection' myself :-)
HTTPS is unnecessary, just encrypt comments instead Posted Feb 18, 2011 8:47 UTC (Fri) by epa (subscriber, #39769) [Link]
jA0EAwMCUvpdZW+4gKhgyUEbVaRtmGoQZfH3qZiiREgKLo7pz45fjfh4mIix1wfu
fWEhivOE4dVGzqXnyfJMa8GBiU6PpwRoIhcun5KuameHqg== =36GG
HTTPS is unnecessary, just encrypt comments instead Posted Feb 18, 2011 11:03 UTC (Fri) by edlenz (guest, #12021) [Link]
ad3039b31ed3980e09452af71f8a6ab6
HTTPS is unnecessary, just encrypt comments instead Posted Feb 18, 2011 14:15 UTC (Fri) by Trelane (subscriber, #56877) [Link]
"Lemme guess... you sank my Battleship?"
HTTPS is unnecessary, just encrypt comments instead Posted Feb 20, 2011 23:08 UTC (Sun) by Baylink (subscriber, #755) [Link]
You know why this is *actually* amusing, right?
HTTPS is unnecessary, just encrypt comments instead Posted Feb 20, 2011 23:54 UTC (Sun) by Trelane (subscriber, #56877) [Link]
Perhaps; feel free to share, though.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 0:07 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
More like "socially responsible internet usage enabled".
Sometime in the last 20 years crypto went from being obscure and computationally expensive to being dirt cheap and easily available. Unfortunately, most of the internet has failed to notice. A moderately priced desktop CPU can do something like 40gbit/sec of AES now.
While you might be fortunate enough to be free from censorship, harassment, or data theft by criminals, governments or other institutions not everyone is so fortunate. Communication always involves at least two parties and both must operate securely for the security to work, so unfortunately those who are at risk are often unable to take protective measures because it requires convincing everyone else to change too. Also, if services are offered and commonly used unencrypted an attacker can just block the crypto to fake a technical failure.
So for the people who really do need it to have it when they need it, we need to use it all the time.
Additionally, our failure to use encryption ubiquitously has resulted in an industry of surveillance and traffic manipulation which could largely have not existed otherwise. Those industries promote censorship, unlawful surveillance, and other harmful practices even where there was previously no interest because the products have already been built.
Finally we don't always know what the risks are. If confidentiality takes additional effort we'll forgo it, and possibly later regret the decision. There are a lot of pedestrian risks too I would speculate that a lot of LWN readers use the same passwords user accounts on systems they run, so secure login does have some real benefits.
(Yes, that is terrible practice. But how many more years will we continue to blame the victims for 'bad practices' before realizing that this issue is not going away and we begin to engineer in more ways to mitigate harm?)
So it absolutely is a good thing to see more SSL deployed, even on "low impact" things like LWN. Hopefully this works out well and LWN will some day be able push all users to SSL using strict transport security. It's the socially responsible thing to do.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 3:40 UTC (Fri) by wahern (subscriber, #37304) [Link]
Can SDRAM do reads and writes simultaneously? Otherwise, a desktop CPU couldn't do 40Gb/s unless it's just encrypting the same data over-and-over again in the cache.
The primary issue with HTTP SSL throughout isn't encryption, anyhow, it's key exchange. The work on that is several orders of magnitude greater. Now multiply that work times 100 or 1000 or 10000 on a server system. It hurts. I haven't yet seen a public implementation of SSL session caching across server farms, which means it's not being done much, if at all. Which means scaling a site to use SSL ubiquitously is still a hardware challenge.
Secondly, for raw throughput you can't just consider AES. Every SSL message also needs a MAC, usually with SHA-1 or SHA256. Depending on implementation and message sizes this could double the cost.
Thirdly, with the rise of tablets and smartphones we're taking a giant leap backwards in terms of raw processing power. A lot of optimization is taking place to keep graphics and the user experience at par. And even the iPad, I think, has AES acceleration. But AFAICT none have RSA, ECDH, ECDSA, or other bignum chips. (And who provides EC certificates on port 443 anyhow? Nobody.)
New LWN feature: HTTPS-only access Posted Feb 18, 2011 5:59 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
5Gbytes/sec is well within the memory bandwidth on the i7, though I never intended to imply that you'd actually get that much performance in practice on a system actually doing something real and not just running AES as fast as possible. The point I was trying to make is that it's now very small and in practice the symmetric crypto should never be an issue. This wasn't the case 20 years ago. Sorry if implied otherwise.
Shared session caching certainly exists: E.g. http://distcache.sourceforge.net/ And there are _enormous_ commercial deployments, for sure. Keep in mind that if you're doing a SSL session negotiation to secure the login (which is widely done and the minimum sane thing to avoid really negative consequences) then the public key workload should be a non-issue given sufficiently mature software and the right design on the sevice. More work is needed in this area. Where does the software come from? Catch-22. Hyperthreaded CPUs also help with this somewhat most webserverish loads are memory bound, and the public key stuff can keep the execution units busy while another process is waiting on ram.
Unfortunately SSL makes some somewhat unfortunate decisions for scaling on the server side. TCPcrypt offers a massive improvement when used in combination with SSL, and I hope it's successful: http://tcpcrypt.org/
On the pandaboard, which a dual core arm (omap4) now being used in some mobile, devices using opeenssl (which I would be really shocked if it was well optimized for this platform) with a single core does 1,999 RSA-1024 verifies (what an SSL client must due) per second or 611 RSA-2048 verifies per second. Even on an order of magnitude slower arm this is not really slow enough that it should be a reason to avoid the crypto.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 18:27 UTC (Fri) by wahern (subscriber, #37304) [Link]
I am humbled :)
New LWN feature: HTTPS-only access Posted Feb 18, 2011 18:20 UTC (Fri) by b7j0c (subscriber, #27559) [Link]
i am so sick of these comments. yes, there is a cost to persistent ssl. so what, suck it up, we are sick of relying on script hackers to secure our cookies
New LWN feature: HTTPS-only access Posted Feb 18, 2011 0:16 UTC (Fri) by nyfle (guest, #72967) [Link]
Seems I picked the right day in which to become a subscriber. :-)
New LWN feature: HTTPS-only access Posted Feb 18, 2011 1:42 UTC (Fri) by pr1268 (subscriber, #24648) [Link] Welcome to the LWN crowd! Also, just an observation: As of February 2011 the LWN subscriber/guest numbers are up to almost 73000. Yes, I realize that includes non-active/expired/abandoned accounts, but still I think it's an interesting statistic. (I suppose our editors would be pleased if the subscriber number went well into the 6-digit range, but I digress.)
New LWN feature: HTTPS-only access Posted Feb 18, 2011 2:59 UTC (Fri) by lutchann (subscriber, #8872) [Link]
I expect it also includes thousands of accounts created by spambots. If so, our editors may not be that happy about hitting the 100k mark.
New LWN feature: HTTPS-only access Posted Feb 24, 2011 23:24 UTC (Thu) by rswarbrick (subscriber, #47560) [Link]
Those spambots must have deep pockets, even with "Starving Hacker" subscriptions.
New LWN feature: HTTPS-only access Posted Feb 20, 2011 23:36 UTC (Sun) by Baylink (subscriber, #755) [Link]
Yeah, that is kinda neat, isn't it?
New LWN feature: HTTPS-only access Posted Feb 18, 2011 0:30 UTC (Fri) by Tar (subscriber, #2456) [Link] HTTPS RSS feed still points to HTTP articles: https://lwn.net/headlines/newrss
New LWN feature: HTTPS-only access Posted Feb 18, 2011 0:34 UTC (Fri) by corbet (editor, #1) [Link] There's all kinds of things that have http: links, including a lot of text which has been written over the years. There's no way that they're ever all going to get fixed.If you turn on HTTPS-only and to go an HTTP URL, the site will redirect you to the SSL version. The authorization cookie is marked "secure," so it won't be sent before the redirect, and thus won't be exposed. The end result is not as efficient as one might like, but it does properly protect against session hijacking and such.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 0:55 UTC (Fri) by ovitters (subscriber, #27950) [Link]
If you set the following header browsers (works in Firefox 4.0) will only connect to https, even if you/someone links to http:
https://developer.mozilla.org/en/Security/HTTP_Strict_Tra...
New LWN feature: HTTPS-only access Posted Feb 18, 2011 0:55 UTC (Fri) by jeroen (subscriber, #12372) [Link] If you use HTTP Strict Transport Security those HTTP URLs won't be a problem, because the browser will automatically transform those URLs to HTTPS URLs and never make a non-secure connection.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 1:33 UTC (Fri) by jengelh (subscriber, #33263) [Link]
Relative URLs do pay off. Especially when the source strings begin with qr!http://lwn.net/!.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 2:19 UTC (Fri) by thyrsus (subscriber, #21004) [Link]
I turned this on, and advertising went away. I'm running Firefox. It may have to do with an interaction with noScript (https://www.informaction.com/), in which I allow scripts from lwn.net but not googlesyndication.com. I'm also using the HTTPS-Everywhere tool. I wouldn't mind googlesyndication.com running on lwn.net pages, but there are other places (e.g., yahoo.com) where I don't want it running.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 2:23 UTC (Fri) by thyrsus (subscriber, #21004) [Link]
Retraction: advertising didn't go away completely - I now see a TrustCommerce ad underneath the upper left hand LWN.net logo. This is not a complaint!
New LWN feature: HTTPS-only access Posted Feb 19, 2011 0:36 UTC (Sat) by Tobu (subscriber, #24111) [Link] URLs without a scheme are protocol-relative URLs. For example, ://wordpress.com/ and ://lwn.net/ will be retrieved with the same protocol that was used to access the page that links to them.
New LWN feature: HTTPS-only access Posted Feb 19, 2011 1:14 UTC (Sat) by Tobu (subscriber, #24111) [Link] That should read //wordpress.com/ and //lwn.net/ (source). Though it may not work for feeds, where the base uri might not even be http, and it is not useful for links within lwn.net that can omit the host as well. Strict-Transport-Security is more relevant.
New LWN feature: HTTPS-only access Posted Feb 20, 2011 23:40 UTC (Sun) by Baylink (subscriber, #755) [Link]
Well, that's silly.
With the leading colon, at least you can intuit what it might have thought it was.
With*out* the leading colon, it's now an SMB UFN name, and therefore ambiguous.
New LWN feature: HTTPS-only access Posted Feb 21, 2011 0:05 UTC (Mon) by nybble41 (subscriber, #55106) [Link]
No, without the colon it it unambiguously a URL without a protocol field. SMB UFNs of the form //host/... are not valid in places where URLs are expected, at least not without being reformatted as "file:" URLs. (I expect the standard \\host\... form would be accepted as an SMB UFN, although it could also be parsed as a relative URL containing backslashes in the component name. The "file:" syntax is a bit safer.)
Most pages only partially SSL Posted Feb 18, 2011 0:32 UTC (Fri) by jpnp (subscriber, #63341) [Link]
Of course, what I actually get for most pages is a "mixed page" as the ads are not served through SSL. Thus my browser doesn't show the UI that it uses for a secure connection, and, in principle, someone could inject "bad stuff" into the page by intercepting the google ads.
If secure by default is going to take off it will need ad networks to serve over SSL too.
Most pages only partially SSL Posted Feb 18, 2011 17:45 UTC (Fri) by iabervon (subscriber, #722) [Link]
Considering the way ad networks work, it would be way easier to insert bad stuff by buying an ad and serving bad stuff in it than it would be to hijack the HTTP connection and substitute bad stuff due to the connection being insecure. Ad networks using HTTPS wouldn't prevent the easy attack, but would avoid that warning, giving users who care a false sense of security.
The right thing, of course, would be to arrange for ads to be rendered in a context where they can't attack the secure page, and have browsers not mind that the ad isn't secure while the page containing it is.
Most pages only partially SSL Posted Feb 19, 2011 11:52 UTC (Sat) by jpnp (subscriber, #63341) [Link]
Point taken, but that seems to be a rather different attack: https only ensures you haven't been snooped on, or MITM'd; it doesn't stop you having to trust the end points (i.e. both LWN and Google in this case).
If you wanted to hack random people, perhaps to add to a botnet or to fish for financial details, then buying some ad space and serving badware might allow you to get code into some secured sites.
If you wanted to hack me specifically, perhaps because I'm attached to your WiFi service, or you're a dodgy ISP (or just any ISP in a state with dodgy security services), then it's quite hard to buy the right ads to get the targeting you want. It would be even harder to do it without notice. If you're the one supplying the infrastructure, it's much, much easier to do MITM attacks on unsecured content.
Sites have been hacked after placing unsecured google ads on an https log-in page. The recent facebook episode in Tunisia shows what can happen to unsecured pages. Redirecting facebook to https, but doing nothing about the ads, changes nothing.
Most pages only partially SSL Posted Feb 19, 2011 19:53 UTC (Sat) by iabervon (subscriber, #722) [Link]
I'm not entirely sure how Google does their ads, but any system that does targeted advertisement based on will let you bid on requests based on kind of arbitrary characteristics of the request, under the assumption that the you've somehow figured out your target market using your own special analytics that the ad network wouldn't know to do. So you could buy ads which will be sent to your WiFi service's NAT address, and, if you were serving them over HTTPS, you could probably get them served only on HTTPS pages. If you were doing campaign ads for a Tunisian political candidate, you might buy ads on Facebook pages in Tunisia (because Facebook users are more likely to care about voting and people outside of Tunisia probably aren't part of the electorate), which would result in an HTTPS connection to a site of your choice which will be trusted by the user's browser based only on legitimately having some arbitrary hostname the user will never see. With ads, the end point is really the advertiser (not, in most cases, the ad network), and it is not too hard for an attacker to get that role.
HTTPS for the main content does stop a bunch of the easiest attacks (snooping the session cookie, snooping the page content), so it's worthwhile. Securing the ad connections only prevents more difficult routes than ones it doesn't prevent, so it's not really worthwhile. If, for example, Facebook vetted and served the ads that appeared on Facebook pages, that would be worth securing, but the current environment doesn't work like that.
Most pages only partially SSL Posted Feb 20, 2011 0:03 UTC (Sun) by jpnp (subscriber, #63341) [Link]
There is a valid point here about the trustworthyness of any embedded content from different domains to the one the browser shows details for, but things would still be better if ads could be served over https.
Firstly, not all ads are served from the buyer's own servers. A pertinent example being LWN where the ad requests seem to go to either lwn.net/AdServer, googleads.g.doubleclick.net, or pagead2.googlesyndication.com.
Secondly, even if you could target me directly by buying ads for specific IP address as you suggest (I don't know if this is possible on any common ad networks), you leave far more record of what you have done, including the financial details you use to pay for it.
Thirdly, the ad request includes the URL of the requesting page. Exposing in the clear to eavesdroppers (no active attack required) which pages I was viewing, if not the content. An information leak you may not appreciate.
I have no idea, and rather little interest in, what facebook does with its ads, but I would certainly prefer it if google offered https ads.
Of course, none of this matters much for LWN, but the principle applies more widely.
Advertising Posted Feb 20, 2011 16:02 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
The situation on the advertising-supported web is quite extraordinary, unprecedented really, and probably because the people making the big financial decisions don't have much technology understanding. Smaller outfits like LWN have to go along with the flow, despite it being insane, because they don't have the financial clout to insist on anything better.
The advertisers get to insert arbitrary text, images, program code, without any prior oversight by the publisher. In the event that they are caught doing something forbidden by the contract terms, or even outright criminal, the most that is likely to happen is that they forfeit the remainder (if any) of their pre-paid advertising, and even this can take days or weeks after the advert was published.
Imagine if you bought a newspaper and on page 4 you read an article which appeared to be written by a staff journalist about the fact that Pepsi was contaminated with effluent from chicken farms and dozens of people had died. Would your first thought be "I bet this is just a Coke advert, and the paper had no way of knowing it would appear until after the paper was delivered to me" ? Of course not, newspaper publishers insist on vetting every advertisement, and deal only with a handful of reputable agencies. They don't want to get sued or prosecuted every five minutes and they don't want their reputation (such as it is) harmed by such shenanigans.
But on the web this has become normal. The major World of Warcraft sites are constantly flooded with advertisements for services which violate the WoW T&Cs and for scams, phishing sites, and similarly dubious things. Many of them inject script to capture clicks anywhere on the page and use them to dodge "event must be user-initiated" restrictions in browsers like Firefox, creating pop-ups, stealing referrals, and so on. All forbidden by the advertising contract, but very lucrative. The companies and individuals running those sites despair of doing anything about it. Some operate an LWN-like system where you can subscribe and turn off adverts, but of course the majority of their revenue comes from advertising supported browsing, they probably have 1000 casual visitors for every user, and 1000 users for every paying subscriber, so they can't just switch off adverts altogether.
Any site about health which carries advertisements will be dominated with products that make outright illegal claims. Books on how to cure cancer "100% guaranteed", unlicensed devices, pills and creams. Such adverts would almost never run in a newspaper or on TV because the publisher or broadcaster checks for such violations, but on the web it's a free-for-all.
Available to non-subscribers Posted Feb 18, 2011 2:05 UTC (Fri) by tamasrepus (guest, #33205) [Link]
Thanks for making HTTPS-only access available to non-subscribers!
(Yes, I know; I'm working on becoming a subscriber myself
)
New LWN feature: HTTPS-only access Posted Feb 18, 2011 3:21 UTC (Fri) by eli (guest, #11265) [Link]
Seems to work, and ads still show up in my case, and hm... I didn't get a warning about partially secured content. Thank you for adding this feature. I hope that once you've run this way for long enough to be comfortable with it, you will make it the default.
Actually, is there a reason to have http do anything more than redirect to the equivalent https url?
New LWN feature: HTTPS-only access Posted Feb 18, 2011 5:04 UTC (Fri) by cuboci (subscriber, #9641) [Link]
Thanks a lot for that, it is most appreciated. Finally, someone's doing the right thing.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 6:00 UTC (Fri) by mrons (subscriber, #1751) [Link]
Hmm, the GreaseMonkey script I use to keep track of comments read, needs to start again with the new HTTPS pages.
Oh well, no big deal. Lucky it didn't happen during one of those giant threads.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 6:19 UTC (Fri) by mrons (subscriber, #1751) [Link]
And I needed to edit the script, Tools->GreaseMonkey->Manage-User-Scripts, and change the two occurrences of http://lwn to https://lwn. One of those occurrences seemed to be in a comment.
After restarting my browser, it keeps tracks of comments again.
I'm not too worried about the old tracking information.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 10:11 UTC (Fri) by maniax (subscriber, #4509) [Link]
<ruleset name="lwn">
<rule from="^http://www\.lwn\.net" to="https://www.lwn.net"/> <rule from="^http://lwn\.net" to="https://lwn.net"/> </ruleset>
A ruleset for https everywhere. I can also be submitted to the official site, but I think it should be done by lwn, not myself :)
New LWN feature: HTTPS-only access Posted Feb 18, 2011 13:54 UTC (Fri) by njwhite (subscriber, #51848) [Link]
Lovely, thanks very much for this.
Now that's done, I'd love an OpenID login option. That way I could use my https://certifi.ca/ certificate to authenticate, and I'd be in heaven ;-)
New LWN feature: HTTPS-only access Posted Feb 18, 2011 20:15 UTC (Fri) by daniel (subscriber, #3181) [Link]
"Me too". Thankyou very much, Jon
New LWN feature: HTTPS-only access Posted Feb 18, 2011 14:40 UTC (Fri) by welinder (guest, #4699) [Link]
Well, I get kicked off https even when I ask for it explicitly:
welinder@sequoia:~> wget https://lwn.net/daily/
100%[======================================>] 26,266 158K/s in 0.2s
2011-02-18 09:38:40 (158 KB/s) - `index.html' saved [26266/26266]
New LWN feature: HTTPS-only access Posted Feb 18, 2011 15:10 UTC (Fri) by corbet (editor, #1) [Link] Bear in mind that lwn.net/daily is a link which hasn't really meant anything since early 2002. When the "new" site code went in, I did my best to avoid breaking URLs, so that one redirects to a working location. It's not surprising that it goes to a non-SSL URL, though.Over time, we'll be fixing hard-coded http:// URLs in the site code itself. But it doesn't strike me as the highest-priority task, so it won't happen instantly.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 18:03 UTC (Fri) by welinder (guest, #4699) [Link]
Fair enough. I can adjust my link.
(There might be a statement about me being a petrified old fart
Thanks LWN! Posted Feb 18, 2011 17:58 UTC (Fri) by david.a.wheeler (subscriber, #72896) [Link]
This is very nice. Thanks, LWN!!
New LWN feature: HTTPS-only access Posted Feb 18, 2011 19:01 UTC (Fri) by josh (subscriber, #17465) [Link]
Thank you very much for this. One less insecure site I have an account on.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 20:44 UTC (Fri) by MattPerry (guest, #46341) [Link]
Why is it restricted to logged in users? Why not just switch to SSL for everyone whether logged in or not? The load can't be high for a nearly text-only site with today's fast servers.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 20:54 UTC (Fri) by corbet (editor, #1) [Link] The main reason we don't just do full-time SSL is that browsers will pop up a warning because a certain well-known advertising provider doesn't see fit to make an SSL version of its offering. The sad truth of the matter is that a big this page is not really secure! panic! dialog is just not the way we want to welcome new readers to our site.Beyond that, there's no session cookie to snarf, so the stakes are lower. Still, we'd rather do all-SSL if we could.
New LWN feature: HTTPS-only access Posted Feb 18, 2011 21:14 UTC (Fri) by MattPerry (guest, #46341) [Link]
Thanks for the explanation. That makes perfect sense.
New LWN feature: HTTPS-only access Posted Feb 19, 2011 0:51 UTC (Sat) by welinder (guest, #4699) [Link]
> The main reason we don't just do full-time SSL is that browsers
> will pop up a warning because a certain well-known advertising > provider doesn't see fit to make an SSL version of its offering.
Could you proxy those?
(Assuming that the certain well-known advertising provider's rules
New LWN feature: HTTPS-only access Posted Feb 19, 2011 7:37 UTC (Sat) by sumanah (guest, #59891) [Link]
Thanks for this!
New LWN feature: HTTPS-only access Posted Feb 19, 2011 14:10 UTC (Sat) by Thue (subscriber, #14277) [Link]
It is not secure until all the files included in the page are also https. Which they are not, as my browser is (rightly) complaining about.
Often, when you have the ability to eavesdrop on a data stream, you also have the ability to change it with a man-in-the-middle attack. So it is slightly silly to have a https-page include a javascript file via http. If anybody wanted to eavesdrop, they could still get most info by changing the javascript file to report on what I was doing.
New LWN feature: HTTPS-only access Posted Feb 19, 2011 14:13 UTC (Sat) by mpolacek (guest, #66426) [Link]
Great! Thanks a lot.
New LWN feature: HTTPS-only access Posted Feb 19, 2011 16:50 UTC (Sat) by andrel (subscriber, #5166) [Link]
I hope that later this month the security page will feature an article about this change answering things like how this is better than the previous setup, why this still isn't perfect, what changes had to be made to the CMS, how it effects your server load, etc. etc.
New LWN feature: HTTPS-only access Posted Feb 19, 2011 17:36 UTC (Sat) by Trou.fr (subscriber, #26289) [Link]
Good news, now if you could switch from plaintext passwords in the DB to (correctly, like bcrypt) hashed passwords... that would be even better :)
Passwords Posted Feb 19, 2011 17:37 UTC (Sat) by corbet (editor, #1) [Link] That's pretty much at the top of the list and will happen soon. I agree we should have done it a long time ago.
Passwords Posted Mar 1, 2011 5:19 UTC (Tue) by i3839 (guest, #31386) [Link]
I'm sure that would have been fixed if you had open sourced the site's code. ;-)
Great! Posted Feb 19, 2011 18:13 UTC (Sat) by NikLi (guest, #66938) [Link]
Thank you very much! Fantastic news!
One problem with SSL though is that the "Certificate Authority" is able to create a certificate for somebody who would like to do man-in-the-middle and there is no way one can detect that. The security is based on the fact that CAs will not jeopardise their "Authority" because if one was to show such a crafted certificate ("Here, this is signed by Equifax, sais that it's lwn, but this is not lwn's key.") it would be proof that the said CA has committed a crime and can even stand in court.
So, it is a fact that SSL protects us from script hackers who sniff wifi, but it cannot protect us from those who are more powerful than the CAs, like the guys at sector 9, where Nikita used to work :)
So, pardon my sceptisism, but i'm still waiting for Freedom Box before i get really excited. The other bad thing with SSL is that we cannot debug HTTP and see what Safari does these days, but that's another problem...
UR the best and i am happy i'm considering subscribing though.
Great! Posted Feb 21, 2011 0:15 UTC (Mon) by Baylink (subscriber, #755) [Link]
> One problem with SSL though is that the "Certificate Authority" is able to create a certificate for somebody who would like to do man-in-the-middle and there is no way one can detect that. The security is based on the fact that CAs will not jeopardise their "Authority" because if one was to show such a crafted certificate ("Here, this is signed by Equifax, sais that it's lwn, but this is not lwn's key.") it would be proof that the said CA has committed a crime and can even stand in court.
Has this not already happened IRL somewhere, last year, I think?
|
|||||||||||||