Security Collapse In the HTTPS Market 185
CowboyRobot writes: HTTPS has evolved into the de facto standard for secure Web browsing. Through the certificate-based authentication protocol, Web services and Internet users first authenticate one another ("shake hands") using a TLS/SSL certificate, encrypt Web communications end-to-end, and show a padlock in the browser to signal that a communication is secure. In recent years, HTTPS has become an essential technology to protect social, political, and economic activities online. At the same time, widely reported security incidents (such as DigiNotar's breach, Apple's #gotofail, and OpenSSL's Heartbleed) have exposed systemic security vulnerabilities of HTTPS to a global audience. The Edward Snowden revelations (notably around operation BULLRUN, MUSCULAR, and the lesser-known FLYING PIG program to query certificate metadata on a dragnet scale) have driven the point home that HTTPS is both a major target of government hacking and eavesdropping, as well as an effective measure against dragnet content surveillance when Internet traffic traverses global networks. HTTPS, in short, is an absolutely critical but fundamentally flawed cybersecurity technology.
So offer a cost effective replacement (Score:5, Insightful)
Yes HTTPS is flawed. Name one protocol that is not.
Unless someone can offer a cost effective replacement (IE one that can be deployed and scaled into without breaking existing technology) then the best approach is to continue and fix the flaws as they are found.
The solution to a problem is not always "throw it away and re-write it". In fact the longer you are around in technology, the more you will realize that this is hardly ever a good idea.
Re:So offer a cost effective replacement (Score:5, Insightful)
As with all security, your requirements depend on your threat model. What are you trying to protect against?
I suspect most of us just don't want thieves stealing our bank passwords, social security numbers, or credit cards.
HTTPS is probably sufficient for that.
If you're trying to make sure the NSA can't get at data of yours that it wants, you need something else. What that is, I don't know.
Folks.... (Score:5, Interesting)
It's not HTTPS that's insecure, it's the current certificate authenticity chain.
Eliminate that chain, work out a public exchange and verification program (something akin to bittorrent for
gpg signed certificates from other people you trust.) and plug that in in place of the current certificate authority
model and you're set.
This does of course require you to have people you trust who have some way to verify they got the 'original'
copy of the certificate, and doesn't preclude using the equivalent of modern certificate authorities if desired.
It simply provides 3rd party verification if something appears to be up.
If you need a good example of how this might be carried out, look up 'WASTE', then imagine combining that with slashdot's rating system utilizing the old Kevin Bacon skit about 6 degrees of separation. That should provide secure peering with a layer of trust model that would dwindle the farther away from you a 'trusted individual' is positioned. It's not as 'cheap' in terms of cpu, disk space, or memory requirements as the current system, but it would be harder to exploit than the current centralized system.
Re:Folks.... (Score:5, Insightful)
Mod parent up. While the poster's solution may not be the right idea, he's absolutely identified the problem: profit-driven central authority.
Re: (Score:2, Insightful)
The problem is not that it is for-profit. The problem is rather that we're supposed to implicitly trust them despite us having no reason to do so, and in the light of various revelations lately, have every reason to actually DIStrust a fair lot of them. Not because they are "evil". Just because they could not defend against the country they reside in requiring them to ... let's say "comply".
Re: (Score:2)
It's that we trust 400 of them by default in the first place, and any one of them should be easy enough to subvert by a sufficiently powerful nation-state.
Some of them are directly run by nation-states.
Re: (Score:3)
For example: Hong Kong Post Root; DoD Root CA 2; Federal Common Policy CA; Staat der Nederlanden Root CA - Any of these CA can mint a certificate for ANY website.
Keep in mind that any sufficiently powerful nation is better served sending lawyers rather than hackers. Step One: All it takes is to send a court ordered warrant with gag-order to get the private key for "Go Daddy Root Certificate Authority - G2". Step Two: Mint certificates
We should do two things. 1) Browsers should also start displaying the ro
Re: (Score:2)
Eliminate that chain, work out a public exchange and verification program (something akin to bittorrent for gpg signed certificates from other people you trust.) and plug that in in place of the current certificate authority model and you're set.
Or rather than eliminating it, secure it. A couple of proposals:
http://www.certificate-transparency.org/ provides a distributed mechanism for near real-time monitoring of certificates in use, to very quickly identify and block certificates that weren't issued legitimately.
http://convergence.io/ makes the observation that MITM attacks result in some subset of the Internet seeing a different certificate from a given server. A distributed system of crosschecks identifies sessions which are being attacked.
Re: (Score:3)
DNSSEC + DANE
It limits the damage a lot more then the current "trust the CA completely" model. A rogue CA can only damage / MitM certificates that they have issued without raising red flags in the SSL stack.
Is DNSSEC+DANE perfect? No, it has some rough edges
Re: (Score:2)
A decent stepping stone would be to allow multiple CA signatures on a certificate. Then, a user can decide how much they trust a certificate based on which CAs trust that certificate. As an added bonus, and verified through DANE [wikipedia.org] or the like, it would be necessary to compromise multiple CAs in order to present a forged certificate. This moves us toward the big web of trust that you propose.
Once this is set up, we can start pruning the massive implicitly trusted root CA list and bring a little sanity to who w
Re: (Score:3)
Re:So offer a cost effective replacement (Score:5, Interesting)
Re:So offer a cost effective replacement (Score:5, Insightful)
Sounds like you just listened to the Apple Pay part of their announcement at the beginning of the month.
Re: (Score:2)
Re: (Score:2)
Apple Pay is WAY more than NFC. It's what the GP said.
Re: (Score:2)
15 years ago I had an MBNA credit card. On their website you could generate a one-time credit card number that was only good for the stated amount. That was a big improvement. I guess not enough people bothered to use it though.
Re: (Score:2)
Re: (Score:2)
Which, interestingly enough, a one-time-use, generated-on-the-fly, disposable credit card number would ALSO protect you against...
Which kinda suck for use as a recurring payment method.
Re: (Score:2)
15 years ago I had an MBNA credit card. On their website you could generate a one-time credit card number that was only good for the stated amount. That was a big improvement. I guess not enough people bothered to use it though.
I have this system today, and my "real" card number, while valid, is systematically declined for Internet transactions. It's common enough that Amazon (at least the French Amazon) has an FAQ on the problems it can cause (bigger orders can be split up, and Amazon debits each packet separately). Some sites refuse the virtual card, but I can real-time the on/off switch on my bank's website to use my "real" card number just for the necessary number of seconds. Not ideal, but better than most.
Re: (Score:2)
Not really... it just would have meant the authorities would have needed a proper court order to make Mastercard/Visa/Amex tell them who that one-time number was associated with, and furnish them with a list of every other transaction that person engaged in over some finite window of time. We're not talking about Bitcoins here, just very long credit card numbers still associated with exactly one real-world account, from a universe of potential numbers that's too sparse to effectively guess a valid number (l
Re: (Score:2)
This would have made it far too easy for people to anonymously spend money on drugs and prostitutes.
yeah only the secret service get to hire sex workers not you plebs
Re: (Score:2)
The solution is that I shouldn't have to send my credit card number to every retailer I want to do business with.
The online retailer knows what you are buying and it needs a shipping address, and e-mail address and/or or phone number as a point of contact. Simply shopping the brick and mortar stores exposes pretty much everything anyone would want to know about your health, income, employment, housing, marital status, lifestyle choices and so on.
Re: (Score:2)
In the Netherlands, we have such a system (called "iDeal").
As far as I know, atleast Germany and a few scandinavian countries have similar systems.
I dare bet a lot of countries have such systems as well.
Re: So offer a cost effective replacement (Score:2)
Re: (Score:2)
I really liked PayPal's solution for limiting risk when paying sites that didn't support PayPal. Their Virtual Debit Card product was great. I could provide whatever information I wanted, restrict the virtual card to exactly the amount of the transaction, and optionally allow it for recurring transactions. They were awesome, especially when purchasing from small companies with very little information about if they were legitimate or not.
PayPal if nice and all, but plenty of people fall for the common t
Re: (Score:3)
Why do you care when you are not liable?
Maybe. Sometimes. I'm currently out $120 from a fraudulent charge that was approved anyway (it was a debit card on my bank account). The bank credited me when the fraud report was submitted, but then the merchant came back and said "Well it looks legit to us, even though a completely different name than the one on the card was used, and we shipped the stuff to a different state." MasterCard went along with that, and took my $120 and handed it over to Newegg. Since April, numerous letters, calls, and em
Re: (Score:2)
Re: (Score:2)
Why do you use a debit card when the protections provided under law for a credit card are so much better? [ftc.gov]
Because you need credit for those.
Re: (Score:2)
What about a pre-paid credit card? Get one of those and you can start building up some credit. Unless, of course you have some catastrophic credit event in your recent past.
Re: (Score:2)
What about a pre-paid credit card? Get one of those and you can start building up some credit. Unless, of course you have some catastrophic credit event in your recent past.
I really don't WANT credit. My solution to this is another bank account that only gets funds when I know I'm going to use a card for an on-line purchase or something.
Re: (Score:2)
What about a pre-paid credit card?
I was under the impression that those came with annual fees.
Re: (Score:2)
Beware 'overdraft protection' on that account where they'll extend you some credit and come after you for it later, with a ton of fees on top.
Re: (Score:2)
Why do you use a debit card when the protections provided under law for a credit card are so much better? [ftc.gov]
According to that site:
Well I reported it within 2 days of the charge itself, but I'm still out $120. So it doesn't really work very well. Should I file a complaint with the FTC? Do you think I would actually get a response?
Re: (Score:2)
Re: (Score:2)
I didn't use my debit card over the Internet, the fraudster did. I don't know how they got the information on the card, maybe from Target or something. Maybe a gas pump skimmer, who knows? I saw the charge and disputed it within 2 or 3 days. The bank issued a credit (they called it provisional) and I filled out the fraud form. There were actually 3 fraudulent charges - Nordstrom's, The Gap, and Newegg. The first 2 were no problem, but after about 5 weeks, I got a letter from the bank saying the credit
Re: (Score:2)
This is why you never, ever use a debit card at anything other than an ATM. (Not even at the grocery store for cash back.) That limits where your card details can be skimmed from.
I don't understand why you thought Newegg would do anything? If the bank "lost" the paperwork, you send a certified letter to follow up, and if they still play possum, send a letter to the regulators and (within the U.S.) state attorney's office...
Re: (Score:2)
I don't understand why you thought Newegg would do anything?
Because Newegg claimed the charge was legitimate, even though the name used was not the name on the card, and they shipped it to a different address in another state, AND they told me on the phone it was fraudulent, and cancelled "Steven Tieng's" account with them. So they made a BIG mistake - when the fraud report came in, they told MasterCard, "oh, no, looks legit to me!"
Non skimmable card (Score:2)
Or do it like we do on europe:
rely on chip, instead of magnetic stipe.
(Which can't get skimmed).
Re: (Score:2)
Re: (Score:3)
I would cancel my relationship with mastercard. It might also help to never shop at newegg again and to convince others as well. My highschool job was working retail. I was taught something like one unhappy customer was 200 grand in business.
That story is pretty convincing you. I would make it my goal to make people aware of it.
Re: (Score:2)
Re: (Score:3)
Why do you think caring should stop with liability? The merchant who ends up paying for fraud just raises their prices to make back the lost money. So you are still paying for the fraud whether or not you're directly liable.
Re: (Score:2, Informative)
The problem is what's going to happen moving forward? The logical end game, is total surveillance of everything electronic/physical ( with cam, image recognition ) where the police comes knocking on your door because your phone GPS logs and CCTV show that 2 months ago you were in a house th
Re: (Score:2)
Or our Battle.net accounts, which have better security measures* than anything on your list :-)
*Stronger passwords than my online banking allows plus a one-time pad and SMS confirmation for actions such as changing passwords. My bank has a one-time pad too but from what I've gathered from comments on /. that's not as common as it should be.
Re: (Score:2)
What kind of one-time pad? If it is not a true two factor system (i.e. the old fashioned paper OTP numbers) it's worthless.
Re: (Score:2)
It's just an indexed list of short codes, bank's website tells which index to use when logging in and also when doing wire transfers or other important stuff. Each of the 300 codes are used only once obviously.
Could you elaborate on the worthless systems? Is my bank's system one of those and if not, what would these systems be like exactly?
Re: (Score:2)
Imagine a trojan in your computer that is able to manipulate webpages in between them arriving at your machine and you seeing them. Like, say, a browser plugin. Adblockers and the like do pretty much that. And no, sadly HTTPS is no safeguard against that because these plugins hit after decryption and before encryption, i.e. they get the plain text. Then, the plugin waits for you to make an actual transfer. And here is what happens then:
You type in that you want to transfer, e.g., 100 bucks to Water&Powe
Re: (Score:2)
A few tactical nukes, well placed, should do.
Re:So offer a cost effective replacement (Score:5, Funny)
Spock. I win.
Re:So offer a cost effective replacement (Score:5, Funny)
Paper disproves Spock
Re:So offer a cost effective replacement (Score:4, Funny)
And Spock Scissors Fingers.
Re: (Score:2, Funny)
Romulans kill federation spy.
Re: (Score:2)
LOL ... I thought we were playing Spock, Paper, Scissors.
Re: (Score:2)
One does not simply invite the Romulans.
Re: (Score:3)
For internal use? (Score:3, Insightful)
HTTPS/SSL, but with the signing, distribution, and recovation done in-house. The big SSL vendors seem to often be prone to poor security, as well as possibly succumbing to the demands of certain government agencies and providing "private" keys.
At least if your certificate is signed in-house, you have control of your certs and a certain amount of extra protection against the above. This might not be a good solution for smaller shops, but mid/medium shops could accomplish this, it's just easier to use a "big
Re: (Score:2)
SSL cert vendors should never have your private key, and I've never seen one that needed it. They only sign you public key when you generate a certificate signing request.
Re: (Score:2)
Re: (Score:2, Interesting)
There was an offered solution, and a damn good one that was highlighted here on /.
http://it.slashdot.org/story/12/07/25/1612236/father-of-ssh-says-security-is-getting-worse
SSH extension to http and some clever simplistic key management for end users. DONE.
SSH (Score:2)
http://it.slashdot.org/story/12/07/25/1612236/father-of-ssh-says-security-is-getting-worse
The article linked from that Slashdot story states:
So is the solution just to take everything off the web entirely? But then I realized that can't be right, and the real article is here [networkworld.com]
It's probably good enough (Score:2)
Like all technology, it's really about what you are trying to protect. For most people and applications HTTPS is probably enough, if you're protecting multi-billion dollar transactions or infrastructure then you should use something stronger. Think of it like door locks -- all are flawed, but it's not worth spending $1 million on security to protect a $300,000 house.
I'm reasonably satisfied with the level of protection from HTTPS for my twitter posts and even banking.
As an aside, is the Microsoft HTTPS impl
Re:So offer a cost effective replacement (Score:5, Funny)
Re: (Score:2)
You mean *after* they've been known about for years by blackhats - or far more likely and terrifying - the TLAs.
Re: (Score:2)
Please don't destroy his dreams. Reality is painful.
Re: (Score:2)
IE
The sooner that corporate IT can abandon Internet Explorer (especially IE6), the better off everyone will be.
Re:So offer a cost effective replacement (Score:5, Interesting)
Yes HTTPS is flawed. Name one protocol that is not.
TELNET. Of course "flawless" means "meeting its design goals," it doesn't mean "suitable for any application."
Re: (Score:3)
telnet is great for wathcing ascii art starwars, there is a suitable application
(telnet towel.blinkenlights.nl)
Re: (Score:2)
Problem is that SSL, and to a lesser extent SSH suck, but almost everything out there is worse, barring physically dropping off a large drive array and using one time pads on each endpoint.
SSL for public web servers is tough to fix. Have more than 2 CAs sign a key? What keeps two CAs from being compromised? Have a revocation list, the bad guys can block that from propagating. Have a key get "known" may be an add-on, but some sites use hundreds of server keys and change them out often.
For other tasks, it
DNSSEC with DANE (Score:2)
Have a key get "known" may be an add-on, but some sites use hundreds of server keys and change them out often.
Then let an organization be the CA for its own registered domain, and let it issue certificates for these "hundreds of server keys". DNSSEC with DANE was supposed to do this, at least at the same assurance level that domain-validated certificates are intended to provide.
Other tasks might work with an out of band method for distributing and authenticating keys.
Good luck describing that out-of-band method for distributing the key for every single web site you visit. The only decent proposals I've read are the status quo (X.509), DANE, and Perspectives. Perspectives checks a server's key fingerprint
Re: (Score:2)
Re: (Score:2)
At first I was going to disagree, convinced that the broken logic was better attributed to a football player until I realized that sort is unlikely to be hanging around here. Yours is the more likely explanation. Occam's razor.
locks, doors, ... (Score:5, Insightful)
Every lock, every door can be attacked and broken. It's no different with protocols. We don't stop locking our bikes or cars just because a government soldier with an M16 can shoot the lock open.
Re: (Score:2, Insightful)
Exactly. Security requirements depend on the threat model.
Just because the NSA can read your data doesn't mean the civilian crooks can get your bank password.
Re:locks, doors, ... (Score:5, Insightful)
Physical locks still need to be broken manually, one door at a time.
When it comes to https, all locks can potentially be opened at once, remotely, with the click of a button, and with no sign of intrusion. It's hardly the same.
Re: (Score:2)
Every lock, every door can be attacked and broken. It's no different with protocols. We don't stop locking our bikes or cars just because a government soldier with an M16 can shoot the lock open.
But in real life, we also are better at spotting when locks don't serve a purpose. Most of us don't have double bolt locks on our bathroom doors, and businesses don't keep their doors lock and run out to unlock it for every customer.
Sometimes it's not the door that needs protection, but the valuables themselves.
Re: (Score:2)
If your bike was made of solid gold, then a conventional bike lock would be useless. Also your bike would be very heavy.
The point is that your analogy has some flawed interpretations. What you're saying is that the use value of riding your bike anywhere outweighs the expected cost of its being stolen. That's completely valid. Likewise the marginal cost of a more sophisticated lock may not be worth the marginal reduction in expected theft-cost.
But information has a wider range of uses and values than a bi
Re: (Score:2)
And, thanks to the internet, threats can travel with light speed.
Re: (Score:2)
Is that like "baked with real vegetables", which may or may not imply there's vegetables actually in it? ;-)
Problems with TLS and PKI (Score:5, Insightful)
goto_fail is just a bug like every else. Its a major bug, yes, but its "only" a bug. There are more systemic issues.
PKI is broken. Diginotar was just one indident we know of. CAs can secretly give everybody any cert they want. We need a system where the CAs need have to publish their certs, and which itself can't forge. Certificate transparency only centralises this "tree of trust". We still need to give the tree a ground to stand on. This can be achieved by gossip protocols. With all these measures, we don't need CAs anymore. CA is a multi-million dollar industry, they won't like being obsolete.
Third point: Microsoft. They haven't added usable perfect forward secrecy until april 2014.
Fourth point: the users. They don't care, or other things are more important to them (stability, etc): Most of them don't update their browsers regularly. I don't critizise clicking away security warnings [microsoft.com].
broken implementation! = bad protocol (Score:5, Informative)
OpenSSL's heartbleeed bug was a bug in openssl, a buffer overrun that didn't really have anything to do with ssl. A similar bug in any other server software would be approximately as bad. Where https protocol specified a ping, openssl instead leaked the contents of arbitrary memory locations .
Apple's goto bug was Apple's bug. Again, little to do with the protocol. Ssl/tls/https didn't fail here, the company failed to implement https.
The one "fault" of the protocol in the cited cases could be that it isn't brain-dead simple. Since the standard isn't idiot-proof, idiots can screw it up.
after thousands of years, why now? (Score:3)
Your main point is a good one - there are good reasons for the complexity.
I'm curious about the other thing you suggested. People have been making and breaking ciphers for thousands of years. For thousands of years, every algorithm* has been broken. Why would you say today's won't be? MD5 was believed to be secure for a long time, now it's thoroughly broken. What evidence is there that SHA-3 doesn't have an undiscovered weakness, given that every other algorithm has had some?
Further, quantum computers
and... (Score:2)
If there's a systemic problem (Score:3)
If there's a single systemic problem with HTTPS, it's that we're still largely relying on Certificate Authorities which charge a lot of money. The expense and complexity discourages people from using SSL more ubiquitously.
I'm not saying it's a perfect security scheme, but my point is that the single biggest problem with it is that we're not using it enough.
Re: (Score:2)
If there's a single systemic problem with HTTPS, it's that we're still largely relying on Certificate Authorities which charge a lot of money. The expense and complexity discourages people from using SSL more ubiquitously.
Cost is an issue if you're buying VeriSign certs for hundreds of dollars, but why waste your money? (Answer: nobody got fired for buying VeriSign, and big companies think customers care about the "trust seals"). Other CAs offer OV or EV certs for less than $200/year.
DV certs are incredibly cheap. StartSSL offers DV certs for non-commercial purposes free-of-charge. For paid certs, they only charge for what costs them money: ndividuals can get their ID verified for $60/year and issue unlimited Class 2 certs.
Server Name Indication (Score:2)
DV certs are incredibly cheap.
But the certificate is not the only cost of upgrading from HTTP to HTTPS, as not all browsers still in use support Server Name Indication [wikipedia.org]. Without SNI, a browser can see only the first certificate associated with port 443 of a given IP address, which requires your domain to have its own IP address as opposed to name-based virtual hosting. In the era of IPv4 address exhaustion, some hosts have started charging $60 per year for a dedicated IPv4 address (source: godaddy.com). The leading SNI-ignorant browsers
Good article (Score:2)
Well done, authors obviously spent a lot of time on it. Splitting implementation and deployment was refreshing to see.
Fundamental problem is aggregation of power/value is an irresistible beacon of abuse. From criminals to states the more value protected the bigger the effort to coopt the system.
I have two "practical" ideas which might help slightly..
1. Replace CA's with DANE or something like it. We already have global view of naming.. Trust should flow from ownership of names as a standard feature of do
Re: (Score:2)
I'm convinced that the refusal of browser companies to implement DANE is directly influenced by security services and CAs.
HTTPS is not flawed (Score:5, Insightful)
From a technological point of view, it's a good protocol. It works and when implemented correctly, it's very secure. However, a PKI is not much about technology. It's mostly about organisation. In other words, it's not about PK, but all about I.
And that's were most things go wrong. Yes, Heartbeat was about technology, but people who paid attention moved away from OpenSSL a long time ago. There are more than enough alternatives. GnuTLS and PolarSSL for example. Apple's gotofail was also about technology, but name me one piece of software that is 100% bug free.
The real problem with HTTPS is how it's organized. When I install a browser (or get one via the OS), I also get a shit load of CA's which I'm supposed to trust. CA's from China, Turkey, Taiwan and other countries from which I don't even speak the language. I will never need a certificate from one of those CA's, because I will never need a secure connection with any website protected by their certificates. If the people from Iran were wise enough to realize that they don't need Diginotar because they don't speak Dutch, they would never be at risk because of Diginotar's epic failure. The first thing I do when installing a web browser is get rid of all the irrelevant CA's. Just to be sure, just to be safe.
And that's what's wrong with HTTPS. That's what needs to be fixed. Trust shouldn't be imposed by a browser maker. Trust should be earned.
Re: (Score:3)
I had tried using GnuTLS for a while in one of my builds (with libcurl, I think), but found it didn't always work right while OpenSSL did. I'm not sure if that is because I had to do something different with GnuTLS, but it just wasn't happy as a drop-in replacement.
Anyway, I don't think "trust should be earned" works. If you visit a banking or shopping web site, in what way are they supposed to earn your trust before you do business with that web site? I can't think of a particularly good way (scalable, und
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
but name me one piece of software that is 100% bug free.
printf("Hello, wold!");
$ cat > test.c
printf("Hello, wold!");
$ gcc test.c
test.c:1:8: error: expected declaration specifiers or ‘...’ before string constant
Given that it doesn't even compile, I'd say it's buggy as hell.
Locks are there to keep honest people honest (Score:2)
Security prevents casual theft. When vulnerabilities are found, we fix them, to maintain a basic level of security. Sufficiently determined criminals may be able to break your security anyway. With https, the route that is always open is directly monitoring your computer directly, where the data is unencrypted. They are, after all, criminals - and it is the job of our governments to help chase them down and put them out of business.
What is frightening about the today's situation is the discovery that many w
This PKI paper is a rewrite of a rewrite (Score:2)
Implementation issues rather than design flaw (Score:2)
HTTPS isnt flawed. Any protocol like this would have implementation issues. These are implementation problems, not a problem with HTTPS design itself.
Re: (Score:2)
NSA and resourceful criminals can use 0days, and CA system helps against small criminals. Current protection meets the need, it seems. Not that I think its broken.
Re: (Score:2)
NSA and resourceful criminals
Why the tautology?
Re: (Score:2)
As long as we rely on CAs for trusted certificates SSL will always have an easily-exploited weak link.
We can all agree HTTPS isn't perfect... but both Firefox and Chrome have started pining certificates... At least that's a start.
Re: (Score:2)
Be sure to check out Moxie Marlinspike's blog post about the topic.
http://www.thoughtcrime.org/bl... [thoughtcrime.org]
Re:Technical flaws are beside the point (Score:5, Informative)
Most all the responses I see to this story so far are kneejerk response to the summary, not very relevant.