Government Could Forge SSL Certificates 168
FutureDomain writes "Is SSL becoming pointless? Researchers are poking holes in the chain of trust for SSL certificates which protect sensitive data. According to these hypothesized attacks, governments could compel certificate authorities to give them phony certificates that are signed by the CA, which are then used to perform man in the middle attacks. They point out that Verisign already makes large sums of money by facilitating the disclosure of US consumers' private data to US government law enforcement. The researchers are developing a Firefox plugin (PDF) that checks past certificates and warns of anomalies in the issuing country, but not much can help if government starts spying on the secure connections of its own citizens."
Can we get rid of SSL now please? (Score:4, Informative)
SSL is, and always has been, and ugly hack. End-to-end encryption should be done at the IP layer, not the TCP layer. Now that we have IPSEC, we have a standard way of doing it properly. The only remaining part of the problem is key distribution, but with DNSSec we can put IPSEC public keys in DNS entries and get end-to-end encryption.
A government able to insert something into the chain of trust is still able to fake a connection, but distributing the chain of trust makes this a bit harder. The US government won't be able to insert something into a .cn domain, for example, although the Chinese government can. For the ultra-paranoid, you can publish the same IPSec public key on both and make clients compare the two. Unlike an SSL certificate, the IPSec key is visible to anyone, even people who don't try to make a connection, so it's much easier to spot if someone has tampered with the connection, and will be cached in ISP's DNS caches, making an unnoticed attack much harder.
DNSSEC has a similar attack against it (Score:4, Insightful)
with DNSSec we can put IPSEC public keys in DNS entries
Unless the government compels domain name registrars to sign phony DNS public keys.
For the ultra-paranoid, you can publish the same IPSec public key on both and make clients compare the two.
Which is little different from hosting something at two different domains with TLS certs from different registrars in different countries.
Re: (Score:3, Interesting)
Which is little different from hosting something at two different domains with TLS certs from different registrars in different countries.
It's very different. The server does not need modifying at all. It only needs a single IPSec private key, you are just distributing the public key via two different routes. The client doesn't even need to try connecting in order to verify the integrity of the key, it just needs to try fetching the two different DNS records and comparing their IPSECKEY entries. If they are different, don't connect at all. Importantly, individual clients don't need to do this check; you just need someone to be perform th
Re: (Score:2)
But isn't the point of DNSSEC that the US Government couldn't forge a certificate for a .cn domain? They'd have to have the root key, I doubt China would give that out.
Re:DNSSEC has a similar attack against it (Score:4, Insightful)
It's worth pointing out that the technique described here isn't a "hack" that can be patched, it's an intrinsic feature of public-key crypto, and specifically a direct consequence of unreservedly trusting the CAs. The CAs are capable, using no tricks or computer hackery, of creating as many "redundant" signed certs for the same qualified name as they wish.
Re: (Score:3, Insightful)
The problem with a system that relies on trusted third parties is that these third parties have to be, well, trusted. This implies that they are trustworthy. Have you evaluated all of the CAs on the list included with your operating system and browser for trustworthiness? I know I haven't. I've delegated that to the OS vendor and the browser vendor. Should I be doing this? Do I have evidence that shows that my OS vendor and browser vendor are trustworthy? And whose interest do they work for?
These are
Re: (Score:2)
This is, technically not true with self-signed certificates. Anybody can be a CA. Just self-sign a certificate and use that to sign the certificates of others. The problem is that you're not included by default. Of course, there are some sites that have their own CA, either for business reasons or because they can. They have an internal CA that they use to sign certificate for business purposes. These CAs are verified and pushed to machines, either by Active Directory at Windows sites or some other mechanism. There's no reason that an individual can't do the same when they generate certificates. The problem is that the fingerprint of CA certificates needs to be validated out of band in order for you the avoid a man in the middle attack when distributing the CA certificate to somebody else. This sort of distribution of SSL certificates would not require a trusted third party, but you would need to be able to identify the person or organization giving you the fingerprint and judge their trustworthiness.
But if you still trust the third-party CAs, then this is still subject to the same attack. Even though you've added your CA to the trusted list, a third-party could coerce another CA to sign a certificate for your domain, and then perform a MITM attack on you.
The only way to be sure is to trust no one but your own CA.
SSL is great for protecting credit card numbers (Score:2)
Let's face it, the primary application of a trusted CA is to protect credit card numbers in ecommerce transactions. This is a great technique for that, and is in fact, well designed for that application. BTW, the government wouldn't even have to forge an SSL certificate. The basic premise of SSL assumes the secrecy of certain things. If the government could compel the CA to provide the certificates and keys, they wouldn't even theoretically have to do a man-in-the-middle attack but could circumvent the
Re: (Score:2)
Unreserved trust for CAs isn't an intrinsic feature of "public key crypto", or even of SSL more specifically. Its quite possible to use SSL without trusting any third party CA (though that means you can only deal with people using SSL that you have a preexisting relationship with to exchange certs
Re: (Score:2)
My point is that this isn't a design flaw, and that public key cryptography allows an authority to sign whatever it wishes to sign. The concept of a root CA only signing certificates of people who legitimately hold the name/organization/entity those certs are bound to is sortof... wait...
I've never gotten a cert from a CA, do they ever even make a promise or agree in writing that they won't sign any
Re: (Score:2)
The US government won't be able to insert something into a .cn domain, for example, although the Chinese government can.
I hear you're a looking for a reason for IPSEC and DNSSec not being implemented. Allow me to introduce a candidate answer.
Re: (Score:2)
sudo mod me up
ok :)
Re: (Score:2)
The Certlock thing should help (assuming they do it right and the software itself can be trusted), but the problem could have been fixed by the browser makers long ago if they took security seriously. If I remember right, the problem was discussed years ago in a firefox bug report.
Basically the browser should have features to allow you to be warned if:
1) The CA has changed (still vulnerable to "Gov can forge SSL certs with CA's help")
2) The cert has changed (paranoid mode- the Gov can eavesdrop only if they
Re: (Score:2)
End-to-end encryption should be done at the IP layer, not the TCP layer.
Sorry, but that's nonsense. Encryption should be done at the IP layer as well as by the application; if encryption is only done by IPSEC at a low level, then I have no way of knowing that my connection to my bank is secure, or is even going to the correct site.
To give an example, for a long time I've had my XP laptop at home configured to use IPSEC to talk to my Ubuntu server. Yesterday I discovered that at some point the Ubuntu server had stopped running the startup script that configures it to require IPS
Re: (Score:2)
Re: (Score:2)
You are confusing so many issues here that it's difficult to know how to reply. First, you are not using DNS to distribute your keys, so your experience is not particularly relevant.
How does using DNS to distribute keys tell me whether the connection is really, actually, physically encrypted?
You are also talking about using IPSec for a VPN, rather than for individual connections.
I'm talking about using it for individual connections between PCs..
Second, there is no reason why the TCP/IP stack could not expose a single function for getting the security state of the connection
Why should I trust the TCP stack's idea of whether the connection is secure when my web browser can determine that itself?
There is absolutely no point in using SSL over an end-to-end IPSEC connection.
Unless you actually want to ensure that your connection is actually, really secure, and the only way to do that is for your application to incorporate its own encryption and authentication. Rule #1 of security is
Re: (Score:2)
Re: (Score:2)
So I presume your web browser doesn't use OpenSSL / GNUTLS or whatever your host platform's native SSL library is?
Noep. Sometimes there are advantages to statically linked libraries. :P
Re: (Score:2)
The layer encryption is done on is really irrelevant to this issue, it is the trust model that is broken.
Re: (Score:2)
Even with IPSec, I'd still use SSL because it does encryption on a higher level, and in some cases, is controlled by app versus app. It also allows for client certificates, so I can lock out a host of problems by having a critical external-facing Web server only allow for authentication via a cert on a smart card. Of course, more sophisticated malware can run a MITM attack by compromising the browser and changing text in flight before it leaves the client machine, but that isn't what SSL is designed to pr
Re: (Score:2)
SSL (more exactly TLS) is an established, mature, well-designed secure protocol. It's not the problem. The "remaining problem" you mention though has always existed with PKI: how do you manage certificates, distribute them to all the sites that need them, handle revocation, etc. That's a big issue and there is no drop in easy solution.
If security is really important to you (Score:5, Insightful)
If you really want to be secure and you are using certificates you should be self signing and exchanging the self signed certs with your partners out of band.
Re:If security is really important to you (Score:5, Insightful)
I like the way OpenSSH does it -- Trust On First Use (TOFU). First time you visit a server you're warned of possible MITM and given a fingerprint (which you could have, say, confirmed in person). After that you never see a warning again unless the server's key unexpectedly changes. No forcing you to automatically trust CAs, and no overstated warnings about self-signed certs.
Re: (Score:2)
Whereas the way web browsers typically do things you could be communicating with several hundred different entities and not know it.
Re: (Score:3, Interesting)
The way I see it you have the following levels:
- HTTP (unencryp
Re: (Score:3, Interesting)
Perhaps have Web server certs trusted by multiple CAs, so you might have a level of trust above that. This way, if a website had a cert validated by a CA in the US, Israel, Germany, Russia, and China, one of those CAs might get compromised, but it would take a pretty big international agreement to compromise all of them and generate a bogus cert.
Re: (Score:3, Insightful)
Exactly like Firefox (and probably other browsers): if you delete all the CA certificates, you'll get warned the first time you visit an encrypted site. Firefox shows you the certificate data, and you can accept and mark "Permanently store this exception".
Re: (Score:2)
Precisely. Otherwise, you are always open to a sufficiently sophisticated man in the middle attack.
what no one wants you to know (Score:5, Informative)
And it took you how long to figure this out? Anyone with real security in mind would create their own certificates and sign them. What's always been missing is a convenient way to verify the identify of the person you're communicating with. CAs only help in certain situations. SSL has always been more about encrypted content than identification no matter what people try to tell you.
Re: (Score:2)
Well... it *is* about identity, and limiting the scope of who you have to trust.
With SSL, you trust the computer manufacturer, your hardware configuration, your Operating system, your web browser (and root certificates in your web browser) and the Certificate Authority (which is a corporation under the U.S. government).
Self signed certs are better, but you need a second channel to communicate the certificates securely.
Re: (Score:2)
Generate your own certificates... (Score:2, Insightful)
and distribute them by mail or something. That doesn't help taking to your bank,
but then again if the government wants your bank balance they'll just ask the bank.
Re: (Score:3, Insightful)
Actually, the banks already have a way to distribute the certs: put them on smart cards. The bank can trust the cert because they issued it. The customer can trust the cert because the bank handed it to them.
There are many good security features a smart-card based solution brings to the table. First, the bank is entirely in charge of their own security from end-to-end. There is no trusting of third parties*. The bank is able to uniquely verify the presence of your card, and can refuse to transfer mone
Re: (Score:2)
An even EASIER solution would just be for them to post the fingerprint for their self-signed certificate on a large sign behind the teller window at all of their branches, essentially staging a signing party -- the area behind the glass is protected by lock and key. They simply tell their customers the
Re: (Score:2)
No, I'm sorry but it's a completely unusable solution because it's not easier for the customers to use or understand. Ultimately, many of their customers are stupid, and it's not their fault. 50% of them are below average, after all. The most we can ever hope for is that they recognize "bank == safe place for my money." And that doesn't absolve the bank of the liability to provide that security, at least not if they want to keep having customers.
So all the technical work of security has to end up in the
Re: (Score:2)
Displaying the fingerprint behind the glass would be excellent, but I've long thought that simply putting it on checkbooks, credit cards and correspondence would work nicely. Trying to substitute a fingerprint for a fake cert wouldn't get very far because too many people would see mismatches with the real cert from the website, fingerprints on older correspondence, etc. Even an option to hear the fingerprint somewhere on the organization's phone menu would be great (and so very easy).
and remember... (Score:2)
SSL / HTTPS (Score:2, Funny)
Re: (Score:2)
Re: (Score:2)
Because, if the client-side javascript is being served by the server over the Web, it's vulnerable: an attacker could just intercept the javascript and insert whatever he wants inside, and pass that on to the client, who would be none the wiser. And as it is non-standard, there'd be no tell-tale signs such as http instead of https, that an astute user could see.
Re: (Score:2)
That's the "secret sauce" so to speak of the library.
Security through obscurity... Given enough time and determination, an attacker can intercept and reverse-engineer your library and add as much salt into your secret sauce as he wishes...
The only way to make it secure is to deliver the client part out-of-band over a known secure channel. Anything else may just delay an attack, but not prevent it.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Okay, so how many security experts will put in serious work just to make money for you? If what you're doing is any good, then it will take a lot of work to examine it for weaknesses. They will doubtless want to bill you at their usual rates. At the end of that, at best, what you'll have is a statement that Joe Security Expert couldn't find a serious problem in as many hours as you're willing to pay for, and that's not going to convince anybody competent in the field.
The only way anybody is going to t
Does that mean... (Score:2)
Does that mean that self-signed certificates are now more secure ? :)
Re: (Score:2)
No. This is not a passive attack, it is a man-in-the-middle attack. The government gets an SSL certificate that looks like the remote one. You connect to their computer, thinking it's the remote computer, authenticate, and it then does the same with the remote machine. With a self-signed certificate, this is even easier because any certificate looks the same as the self-signed one.
It does mean that pre-shared certificates (whether signed by a third-party or not) are more secure. Unfortunately, these
Re:Does that mean... (Score:5, Insightful)
A specific self-signed cert, that you have some out-of-band reason for trusting, is extremely secure because only by compromising the computer storing the signing key could an adversary produce a fake one of those.
The problem is, outside of fairly trivial scenarios(corporate intranet with self-signed certs, worker drones' browsers trust that cert by group policy; small group of paranoics who know each other IRL exchange keys under the bridge at midnight), establishing that out of band reason for trusting a cert is a pain in the ass, and not amenable to any particularly clear solution.
CAs are basically the ugly-not-really-all-that-good solution that has the virtue of working in practice. You trust the cert because the big corporation whose business is attesting to the trustworthiness of certs says you should trust it. Easy, simple, and actually works ok from a strictly financial perspective(ie. the amount of money that Verisign can make by selling overpriced sequences of bits that make the magic green bar appear in consumer browsers is greater than the amount that they could make by MiTM attacking a whole bunch of banking sessions and then fleeing to Namibia with their reputation in tatters).
Where it breaks down is non-strictly-financial situations. It is highly unlikely that clandestine cooperation, for surveillance purposes, with state agencies is all that costly to Verisign, or their ilk(and may in fact be lucrative, as doing various sorts of wiretaps is for the telcomms). If your threat space is just occupied by script-kiddies and Ukranian cyber criminals, commercial CAs work pretty well. If it is occupied by state entities who want information rather than money, there is no particular reason to expect them to work.
Re: (Score:2)
I wrote my previous post under the misunderstanding that governmental agencies could get a copy of the original certificate private key, not that they could get a different private key with the same certification information.
That second case of course mean that "trusted" certificates are neither better nor worse than self-signed certificate. This is a MITM attack that only works well in the case of a first connection (as you should be wary of a certificate change as long as the preexisting certificate didn'
Re: (Score:2)
Re: (Score:2)
1. It isn't clear that a contractual relationship would save you from any threats that CA self-interest with respect to reputation isn't already saving you from. Any CA knows that they are dead if the browsers drop them. Further, most commercial applications of the ability to man-in-the-middle somebody are illegal. Thus, the risks of the CA selling you out for some modest commercial gain are already fairly small. On the other hand, you will have a ver
Re: (Score:2)
With further verification (customer manually checks certificates finger-print), both self-signed and CA-signed would be secure, but then you wouldn't really rely on the signature at all, but rather on the fingerprint.
Re: (Score:2)
No. Without any further verifications, self-signed certificates can be spoofed by the common crook, whereas CA-signed certificates can only be spoofed by governments.
Hi.
Please spoof my self-signed certificate.
Thank you.
With fingerprint verification (Score:2)
a self-signed cert becomes more trustworthy than a CA-verified one.
They've Always Been Pointless (Score:4, Insightful)
Re: (Score:2)
Encryption is of limited utility if you aren't sure who your encrypted session is with. Since manual key exchange has practical problems browsers went for the
Unfortunately the major browser vendors have put WAY too many CAs on the trust list meaning that pretty much any significant governement in the world can ask/order someone to generate them a cert for any domain. Some criminals probablly can too.
IMO the proper way to do it would be to have a chain of trust system as part of DNS so the only people who c
Re: (Score:2)
SSL certificates only provide the ability to encrypt communication between a browser and a server. That's all it's for.
No they are not. They are for providing authentication. You would not need any certificates to encrypt communications. Of course, you can then do a man in the middle attack, but you can only get around that by authentication anyway.
Alas, many people have have tried to build in some level of 'trust' to SSL as well, and the money racket that has grown up around issuing SSL certificates on an ad-hoc basis just so someone's browser doesn't complain needs to go the journey.
This has indeed be identified. There are a couple of things with that. 1) SSL certificates are, normally, just issued to the owner of the site. That already provides some security. 2) you can get certificates that provide more trust nowadays.
Those root certificates in your browser are just money for old rope. We definitely need something better.
I'm not so sure that the current SSL c
Banking secrecy laws (Score:5, Interesting)
Many European countries (Germany, Belgium) now have electronic identity cards, which double as PKI signing tokens, with which you can authenticate yourself to web services, such as your bank.
When Luxembourg introduced a similar system [luxtrust.lu] they didn't piggy back it on an id card, but issued "signing stick" and smart cards just for the purpose of PKI.
You may wonder why, especially since an electronic id card is already in planning in Luxembourg as well.
The answer is obvious: many customers of Luxembourgish banks are foreigners, couldn't thus get a Luxembourgish id card, but wouldn't trust their own government's id cards, so an ad-hoc system was needed: Luxtrust.
Unfortunately, Luxembourg doesn't have any native smartcard industry, so they had to buy the chips from the French [gemalto.com]... who just shipped units with a predictable random number generator, dramatically reducing the number of possible private keys. FAIL.
And the BSI [www.bsi.de] institute (which "certified" the cards) "overlooked" this weakness, because the Germans too have a vested interested in spying on communications with Luxembourgish banks. DOUBLE FAIL.
Re: (Score:2)
"And the BSI [www.bsi.de] institute (which "certified" the cards) "overlooked" this weakness, because the Germans too have a vested interested in spying on communications with Luxembourgish banks. DOUBLE FAIL."
That's a pretty serious accusation - personally I would put this strictly in the "paranoid scheming" box unless you've got anything to back up that claim.
Re: (Score:2)
You can suggest that the French can slip a backdoor into their products to compromise a neighboring country, and nobody bats an eye.
But if you suggest that Germany may deliberately overlook a backdoor, everybody is outraged, Germany is a serious country, they don't do that.
Re: (Score:2)
Personally, I don't give France a bad rap at all (unless it has got something to do with their previous nuclear decisions).
I'm just saying that suggesting that BSI, a company that is credited for giving out Common Criteria certifications, is involved in counter-espionage requires at least some indication of guilt on their part.
And they would be doing this by deliberating slipping through a bad implementation made by a (largely) French company - for their next door neighbor Luxembourg no less? And then they
Re: (Score:2)
Interestingly, the Swiss High Court in Lausanne ruled in 2000 that Swiss tax authorities can use "stolen" data to prosecute tax evasion. Similarly to the recent case, the Germans got hand of a CD-ROM containing incriminating banking information and then forwarded data about Swiss citizens to the Swiss authorities.
Source (in German): http://www.sueddeutsche.de/politik/825/502064/text/ [sueddeutsche.de]
Re: (Score:2)
Are you sure they haven't just shipped Debian on these sticks? :)
Quis custodiet ipsos custodes? (Score:2)
I think we've had this debate on /. before, no?
Who do you trust to issue certs? Certainly not Verisign...the UN, then?
no duh (Score:3, Insightful)
Nobody would ever seriously say that x.509's single point of failure for trusted introducers is a good idea; it just happened to be easy to deploy and got some encouragement along the way because some people could make money on it. But as soon as you look at it in terms of security, it doesn't fare very well.
OpenPGP encourages multiple certifiers for an identity: so they're all required to conspire to sell you out. Conspiracies are hard. Build your next network app on top of Gnu TLS and make sure you test with OpenPGP, so that some day we can switch to modern (and by modern, I mean about 1990-level tech) crypto.
BTW, governments are a great example, but always remember that they are not the only entities with capability or motivation to point a gun at someone. And even if you don't believe that, you've got to admit there are multiple governments, and only one of them at most, is accountable to you. Anyone who says that the cert system should be left vulnerable because the public has an interest in making sure that communications aren't "too secure," definitely isn't thinking about all the angles. The inherent weaknesses of X.509 should never have been used as an argument for building the web on it.
Re: (Score:2)
Agree.
BTW, I thought that X.509, (OK in later versions), could support WOT topologies?
Was just not implemented that way; presumably because central authorities liked the 'simple' hierarchical structure...
Of course, regarding 'too secure' systems, look what happens to people who promote them...
http://en.wikipedia.org/wiki/Philip_Zimmermann#Criminal_investigation_by_US_Customs [wikipedia.org]
So trust the CAs a little less (Score:2, Interesting)
There a "fix" that should help a lot: have browsers cache all certificates that they've accepted. Then, whenever a site *changes* its certificate, give a bit fat warning and optionally send the new certificate to some repository of questionable certificates.
If that repository starts to see bogus certificates signed by a CA, revoke that CA's root certificate.
To really make it work, HTTPS should have a mechanism to indicate that a certificate may not be changed until such-and-such a time, and there should be
Re: (Score:2)
But then don't you need a CA for that repository?
What happens when that starts to fail?
Story misses the point (Score:3, Insightful)
Re: (Score:2)
If you want protection from your government, you have to do something about your government.
Even assuming this were a practical solution, what about all the other governments out there, and the CAs within their jurisdictions? It only takes one CA caving to one government—not necessarily yours—to circumvent the trust authentication for any site.
Re: (Score:2)
Re: (Score:2)
Let's say Liechtenstein controls a CA that is trusted by your browser. They can issue a fake cert for mail.google.com and happily MITM all your GMail connections provided they can rig your hosts file or own your router.
As we all know, there is very little you can do about the Liechtensteiner government.
Paranoia is all well and good... (Score:5, Insightful)
Essentially if you really want secure end to end communication with someone that is more or less fool proof and not subject to outside interference you have to manually exchange keys. It's always been this way. Any time you do less you are trusting *someone* other than yourself and person at the remote end. The simple point is that we *have* to trust someone to exist in society. We trust that the government will not suddenly decide to print "Braquats" and declare Dollars (or Pounds, or Euros, or whatever) useless. We trust that the bank won't wander off with all our money. We trust that our ISP isn't just putting up servers that pretend to be the Internet and are slowly stealing everything we type into our browsers. We trust that the grocery store hasn't poisoned all the produce. Virtually every social action we take involves some modicum of trust that the "other guy" is acting in reasonably good faith.
Thus far the certificate authorities have been trustworthy. Could they be compromised? Of course. Could the clerk at the grocery store be bribed to poison all the produce? Of course. Do we have any reason to think the CAs *have* been compromised? Not that I'm aware of. It's pretty straightforward. Are you doing something that needs to be *completely* secret? Exchange keys with the remote end manually. Are you doing something that needs to be as secret as one can reasonably expect while still dealing public entities? Use the CAs. They have an extremely good track record and seem to be about as trustworthy as anyone can reasonably expect.
Re: (Score:2)
Do we have any reason to think the CAs *have* been compromised? Not that I'm aware of.
The fact that someone's selling a box allowing MITM attacks with forged keys is a little bit suspicious... and since there are now so many CAs around the world it should be easy for governments to find one who'll happily sign a fake key for them, or set up trustuswerefromthegovernment.com as a new CA to sign any key they want.
Re: (Score:2)
not exactly, we only don't know that they haven't been untrustworthy. There's a pretty big difference.
Re: (Score:2)
That is utterly misleading. There is no such thing as complete secrecy. It is also wrong to ask yourself: Do I trust this entity unconditionally? You should only trust an institution conditionally. It all depends in what you're using the encryption for. Can you trust CAs for financial transactions? So far, apparently yes. Can you trust CAs with your international trade secrets as a non-US company? NOT a
Re: (Score:2)
... you have to manually exchange keys.
No. You can get most of the way there with a model like that of PGP: if multiple entities that you trust have vouched for the this one, then you have some confidence. This is what the "web of trust" is all about. The CAs fail both counts -- multiple trust paths are not required and why should I trust any particular CA? The article is just pointing out another reason to not trust the CAs.
With real PKI management I could choose for any particular communication whether I trusted the CAs under the jurisd
A couple interesting quotes I've seen about CA's: (Score:2)
-- Paul Vixie - on the NANOG mailing list
(Going from memory here, so the quote may not be exact.)
"In the real world, you prove your identity with documents provided by a government.
In the digital world, why are we trusting certificates provided by 3rd-party business???"
-- a former coworker
Told you so (Score:2)
Here is a link to my own reply previously: http://slashdot.org/comments.pl?sid=1534366&cid=31004066 [slashdot.org]
To summarize - I don't see how the "trust system" has any meaning. I don't actually know anyone at those 160+ companies and I sure as hell don't *trust* any one of them, not as far as I can throw them.
In fact, I don't really trust anyone :) and based on that - see no reason that my SSL connection is more or less safe whether the cert for counterparty is signed by a "good" or "bad" CA. Frankly, I trust my b
"Is SSL becoming pointless?" (Score:2)
Only a fool would rely on SSL based on the certificates that come with a browser to protect against government. That isn't what it is for. While I object to government snooping in principle (I object to pretty much all government activity in principle) I really have nothing to fear from the NSA learning what parts I am ordering from Jameco. Firefox, HTTPS, and Perspectives provide adequate assurance that I am communicating with the company I intend and that some clerk at some ISP can't snoop my credit ca
Self-signed certs are now more secure. Silly. (Score:2)
Use self-signed certs. I am not talking about being more secure when doing online shopping and other silly things, but for personal/company usage.
For example, if I create my own CA and sign my own certs for my mailserver, I will import my CA cert (or accept cert once, on 1st mail retrieval, although more risky), and no matter what certificate government puts when doing mitm - I'll get a warning.
But if I buy a cert from Verisign and think that I am totally safe now, I would never get any warnings if governme
What about a DNS TXT record with hints? (Score:2)
So the problem is that two different CAs could issue certs for the same host, and some have essentially back doors?
Know what I'd like to see? How about a DNS TXT record that tells you what the real, trusted CA for a given site is? Like, let people assert "for my domain, do not trust any certs unless they come from this particular CA", using DNS as an out-of-band channel that would have to be compromised separately from the SSL negotiation.
Wouldn't that be relatively easy to implement (for those who care t
That's what Government is supposed to do... (Score:2)
Enforcing the Law — using, among other things, eavesdropping on communications — and prosecuting wars, are practically the only things, a government of a free country is supposed to do. Because no one else can be allowed to do these things...
Everything else — and I do mean everything: elementary and higher education, personal retirement, health care, communications, transportation — should be left to the competing enterprises. If only because they are much easier to switch from on
There's a simlpe way to do this yourself. (Score:2)
Provable (Score:2)
A single false, signed certificate from anywhere provides undeniable cause to revoke a CA from all browsers.
Mechanisms exist to prevent these "attacks" (Score:2)
A lot of these "attacks" can be prevented by properly implementing your PKI. For example, some of the articles (and several commenters) make mention of "using a Root CA to generate sub-CA's which then generate rogue certs". Sure, the system allows this to happen, but it also provides constraints to prevent it. One of usual "basic constraints" (which is an X.509 attribute) of a certificate is: "Max path length" which means: "how deep can a signature chain extend from me, if I am trusted" For most peop
About f*cking time (Score:2)
Re: (Score:2)
Offtopic:
My favorite bumper sticker was one that I had on my truck back when I was in high school: "I sold your honor roll student the answers."
Re: (Score:2)
Re: (Score:2)
For the return to tin can and string?
No, but it might be time for people to start using Perspectives [cmu.edu]. Which I'd guess is a better version of the new extension these people are making, although I can't really tell due to the PDF being broken (slashdotted?).
Re: (Score:2)
In any case - this will work only when the CA authority is cooperating with the government, but if you are your own CA then you will be in control of the chain.
Of course - your CA server may suffer an intrusion, but it will require a physical attack from an intruder. Especially if your CA server isn't connected to the net. And there are a large number of tricks to pull to detect intrusions in your facilities. Some of them are centuries old.
Re: (Score:2)
Re:Is it time yet? (Score:4, Interesting)
The problem is they don't need to get the cooperation of the CA that is actually in use, only that of one of the long list that your browser trusts.
Re: (Score:2)
We need something new. A distributed certificate authority.
I'm envisioning something like a Massively Multiplayer Online Diffie-Hellman exchange. Math wonks, is something like this in principle achievable?
Re: (Score:2)
You can always physically armor your CA server. One client of mine has a Windows machine which is permanently offline (was activated via phone so it never has touched the Internet directly.) This machine uses BitLocker with a passphrase to encrypt the volumes, and has inside it a USB card with an Aladdin eToken on an internal port. For signing stuff, the client inserts a USB flash drive or a SD card, signs it with the commercial version of PGP, or the signcode.exe utility that is used for Authenticode si
Re: (Score:2)
It isn't just online, of course. Today I had to visit a local courthouse. In order to enter and do my business with the local government, I had to wlak through an airport-style security checkpoint. Clearly I was being searched. Just as clearly, the police officers performing the search had no specific reason to believe that I had committed a specific crime.
I don't remember anywhere in the 4th amendment it says "unless we're scared", and yet these balantly unconstitutional seraches happen everywhere, all
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Never underestimate the bandwidth of a playing card box full of 32GB MicroSD cards.