Mozilla 1024-Bit Cert Deprecation Leaves 107,000 Sites Untrusted

msm1267 writes: Mozilla has deprecated 1024-bit RSA certificate authority certificates in Firefox 32 and Thunderbird. While there are pluses to the move such as a requirement for longer, stronger keys, at least 107,000 websites will no longer be trusted by Mozilla. Data from HD Moore's Project Sonar, which indexes more than 20 million websites, found 107,535 sites using a cert signed by what will soon be an untrusted CA certificate. Grouping those 107,000-plus sites by certificate expiration date, the results show that 76,185 certificates had expired as of Aug. 25; of the 65 million certificates in the total scan, 845,599 had expired but were still in use as of Aug. 25, Moore said.

Comments

I'm so relieved

[NotInHere]

that slashdot wasn't affected by this.

So 3/4 of them would have already failed?

[jandrese]

It sounds from the writeup like most of the sites in question are defunct and that's why they're using out of date crypto. Few sites that people actually visit would appear to be affected.

oh. so nobody's actively managing them?

[swschrad]

hackers, start your engines...

Re:oh. so nobody's actively managing them?

[Charliemopps]

hackers, start your engines...

No ones every managing them. These things are like domain names... they cost pennies and last for years... so despite their importance they fall to the bottom of businesses radar. A place I worked at a few years ago let their multi-million dollar domain expire. The registrar had been sending emails to an employee that had no longer worked there for quite a while...

The end result? It went down on a Sunday, and one of our hourly tech support guys (Making about $10/hr at the time) figured out what happened and registered the domain on his personal credit card and redirected it because he didn't know who to call. He got dinner out with the president of the company who shook his hand, asked him politely if he'd mind transferring the domain back to the company, which he did.

That guy, years later, ended up being my boss and making six figures. It pays to be clever on occasion. He always joked that the company could have sued him for what he did to get the domain back anyway but he was impressed the president thanked him and asked for it back personally.

Re: oh. so nobody's actively managing them?

[corychristison]

Was the domain being used? Or just squatting on it?

If you were actively using it, and it expired, you have a grace period of anywhere from 30 days to 90 days depending on the TLD, when this happened and who the registrar was/is.

With that said, your point is completely valid. Domain names, SSL certificates, and hosting accounts tend to be forgotten. I own a web design/development/hosting company. We actively maintain records of who we need to be dealing with, as well as their managers in the event our contact stops responding. As well, we introduced a fully managed service in which we manage everything for our clients, and we send them a single monthly invoice. Because it is billed every month, their services continue to Just Workâ, and in turn we are keeping consistent contact with them.

We have had the most problems with non-profit organizations. They are typically volunteer run, with a high turn over rate.

Re: oh. so nobody's actively managing them?

[Anonymous Coward]

You said:

If you were actively using it, and it expired, you have a grace period of anywhere from 30 days to 90 days depending on the TLD, when this happened and who the registrar was/is.

He said:

No ones every managing them. These things are like domain names... they cost pennies and last for years... so despite their importance they fall to the bottom of businesses radar. A place I worked at a few years ago let their multi-million dollar domain expire. The registrar had been sending emails to an employee that had no longer worked there for quite a while...

The company was receiving "you are on your grace period, you should do something about it, like right now" emails but ignored them all.

Reading comprehension: a rare, arcane skill.

Re: oh. so nobody's actively managing them?

[Anonymous Coward]

It's quite obvious you don't understand how domain name grace & renewal periods work, then.

When your domain name expires, it immediately becomes unusable. Sometimes the registry changes the name servers, sometimes it simply fails to resolve. The grace period is an extension in time in which you (or your company) can renew it. It does not stay active, but can ONLY be renewed by the current owner.

In order to register an expired domain name you didn't own before it expired, you have to wait until the grace/renewal period is over, then the domain gets placed in a To Be Released Auction and auctioned off to interested parties. The whole process from expiration to release is anywhere from 45 to 90 days. Even then, I've seen domains get delayed being put on a TBR list for months after expiration.

I asked "Was the domain being used? Or just squatting on it?" because:

- If the domain was in use (ie. The companies primary web address), it would take (on average) 3 months before someone who is not the current owner to register said domain. If my companies primary website was down for 3 months, and someone didn't notice until after the grace/recovery period, then there is something seriously wrong with the company.

- If they were squatting on it, and no-one noticed, its a completely different story.

Re: oh. so nobody's actively managing them?

[Anonymous Coward]

You are assuming that the current state of affairs has always been the way things work.
Not so.

Here's microsoft getting a little help to renew a certificate:
http://news.cnet.com/2100-1023-234907.html

Re: oh. so nobody's actively managing them?

[Anonymous Coward]

Don't track responsible parties in a large organization by name, track them by job title. If John Q. Public is in charge of his company's domain registration, the next guy to fill his position will likely assume that responsibility. If you know to ask for the Chief Underwater Basketweaver instead of Mr. Public or his supervisor, it will be easier to get a hold of them.

Re: oh. so nobody's actively managing them?

[corychristison]

Typically we are dealing with IT staff, and Accounts Payable. Titles don't mean much in these area's, so knowing the managers of the departments is useful.

I certainly see your point, though. There are plenty of movers and shakers out there.

FTFA

[Bill, Shooter of Bul]

“All major browsers will alert users of a site using an expired certificate, and of the 107k affected, only 30k were not expired, and so would no longer be trusted by Mozilla as a result of their recent change,”

So not 107K, only 30k. And that's not a real issue. The browsers are correct, the connection isn't secure at 1024. People can complain as much as they want, trust is not something that is eternally granted without condition.

Re:FTFA

[thegarbz]

trust is not something that is eternally granted without condition.

The condition being to grease the palms of a third party?

Re:FTFA

[bondsbw]

People can complain as much as they want

Yep, that about sums up the Internet.

Re:FTFA

[Bill, Shooter of Bul]

I really don't understand people's hang up with the fee. Certs are cheap as hell. I understand they don't really do that much to verify any one's identity, but its so freaking cheap.

How much abuse is there with fake certificates being issued? I've only heard about a couple of cases. Its better than nothing, and certainly worth the small amount of money.

Re:FTFA

[skids]

People can complain as much as they want

Yep, that about sums up the Internet.

Only half. The other half is "and still get screwed over."

The cert authorities as a whole, following NIST recommendations, decided to not just stop issuing 1024 certs, but also to revoke their 1024 root certs, so anything checking CRLs would just break. Months before the actual deadline. They could have just let those certs run out on schedule, but that wasn't good enough for NIST. Moreso, they could have only sold them such that they ran out on schedule (we were sold a 5-year 1024bit cert in 2009 when the deadline had been set at EOY 2011 since 2005). After an extension by NIST from EOY2011 to EOY2013, made in 2011, the number of certs issued with expiry times much past the deadline was likely pretty small (so in case the NIST estimate of when someone would have the compute power to crack our cert was off by 6 months, we had to swap it out a year early distracting us in the middle of more important things.) Anyone concerned enough to worry that an obscene amount of CPU power would be dedicated to compromising their particular cert would have changed them voluntarily, and even the laggards would have likely made it under the wire before any serious attack on their crypto infrastructure. Finally, lots of people use these certs in internal settings where the crypto isn't the sole security and the real value of the cert isn't crypto but the fact that users don't have to install a site-owned PKI CA root certificate to get the "annoying popups" to stop.

Sooo... it was fortunate that almost nothing was checking CRLs during all that, though as a general state of affairs that also needs to be fixed.

Oh sure, the CAs offered free bridge certs to "make up" for the whole thing. Not good enough. They should have comped an extra year on for free or something. Since they didn't there should have been class action suit to make them pay for the hassle.

People need to quit breaking shit on a whim.

Re:FTFA

[lolococo]

So are you saying that money buys trust? How cynical. Let's see how well that goes down in the future.

The whole SSL ecosystem is based on the fact that you can absolutely trust the certificate authorities. The corollary to this is that, if a single CA is breached, then the whole system becomes untrustworthy. I'm confused as to why most of us still refuse to see that. Propoganda and disinformation? Well, the SSL world definitely represents a huge business, and it's clear none of its stakeholders is willing to see it blow up in smoke. Why let the facts and the truth get in the way of business?

Re:FTFA

[RabidReindeer]

Yes. It's being dropped because it gave the illusion of security without the actuality.

Unfortunately, a LOT of very public websites are running on old expired certs, which isn't really any better.

People need to stop thinking that "software doesn't wear out" - meaning in this case, the security vouchers. Bits may remain unchanged, but the world does not, and if you expect the entire cost of the system is what you paid for at the "cash register" without accounting for ongoing maintenance, you're a fool.

Re:FTFA

[Bill, Shooter of Bul]

"So are you saying that money buys trust"

No.

"The whole SSL ecosystem is based on the fact that you can absolutely trust the certificate authorities."

No, it isn't. Trust is not absolute. Learn this. Please.

The more paranoid you are, the less you trust

[penguinoid]

An unavoidable side effect of trusting less is that you trust less. In this case, ancient websites using outdated crypto, won't be trusted. Most of which already are no longer trusted due to expired certificates.

Several things might happen

[Streetlight]

1. If all these sites renew or get proper certificates it'll be a big improvement in cash for the Certificate Authorities.

2. Maybe most of these un-certificated sites will disappear, though it won't mean much for internet congestion if most are not accessed anyway.

3. Maybe swschard's comment that hackers will have a field day is true, although to what benefit to hackers or detriment to site users?

Good

[Threni]

A browser not trusting something that's not to be trusted is a positive thing. Yes, some old sites will suffer. That's how it's supposed to work. They'd better up their game. People expect security to be take more seriously these days, as there is more at stake and more muppets with a lot of time on their hands trying to attack you.

Re:Good

[Anonymous Coward]

I agree, but the danger is that when people see more and more security warnings for sites that they trust or that seem legitimate, they will learn to click through all warnings. Non-browser-related example (because who in their right mind would run Java in a browser): For every Java update I get a "revocation information not available" error. Apparently Oracle can't handle their certificates appropriately. They're not likely to fix it. What should I do? Of course I click through it, because an old Java version is definitely worse than a broken certificate.

Re:Good

[Hamsterdan]

"they will learn to click through all warnings". Kinda Vista's UAC did for Windows users. Besides, people will go to great lenghts to see lolcats.

The way firefox manages this...

[Skuld-Chan]

Firefox doesn't support the OS's built in certificate stores, which makes it a really big pain in the ass to manage certs yourself (like if your managing certs for firefox users at your company) - you basically have to compile certutil and write all kinds of fun scripts for client devices.

If firefox let me co-manage certs I could just re-add the deprecated cert :).

Re:The way firefox manages this...

[kimvette]

Firefox is becoming a real pain in the ass when it comes to certs. I can see displaying a "ZOMG!!! WARNING!!!" when trying to load a low-bit cert, but it fails completely, which makes it unusable for managing more and more enterprise appliances, some of them being brand new. One could go to each and every appliance and LOM module and generate a new high-bit cert but if you've got enough of them in your data center it's a royal pain in the ass to do so.

The solution? Use any browser other than firefox.

Re:The way firefox manages this...

[Anonymous Coward]

Actually, I like the way that Firefox manages CA.

Where I work, they have pushed CA's to PCs. When I connect to https://mail.google.com, and several other sites, in IE or Chrome, no warning. The company's MITB computer is not detected. When I connect with Firefox, I get the proper warning.

Of course, most people think that Firefox is the problem and prefer Chrome until I explain what's really going on. If I want to add the company's CA manually, I can but at least it's my choice.

So 1024 Bits Not Enough Now?

[Anonymous Coward]

I mean, how long does it take to count through 64 bits? Even that is 18*10^18 permutations, or hundreds of years at 1 billion permutations per second. 128 bits should therefore be 'sufficient' in that respect, 256 bits future-proof and 512 bits overkill.

Re:So 1024 Bits Not Enough Now?

[wonkey_monkey]

I'm going to go out on a limb and suggest (and this is just a hunch) that you don't know what you're talking about.

Re:So 1024 Bits Not Enough Now?

[heypete]

Symmetric and asymmetric keys are different things and have different key lengths. One cannot directly compare key sizes between two wholly different classes of ciphers. There are numerous reasons, mostly involving arcane mathematics, why asymmetric ciphers require longer key lengths than symmetric ciphers to offer similar levels of protection.

For example, a 1024-bit RSA key (RSA is an asymmetric cipher) is essentially equivalent to an 80-bit symmetric key (AES, 3DES, etc. are symmetric ciphers). SHA1, a hashing algorithm, provides less than 80 bits of security; those wishing stronger signatures are switching to SHA-256 (which offers 128 bits of security) and SHA-512 (which offers 256 bits).

A 2048-bit RSA key, such as those used by most CAs and web servers these days, has the same strength as a 112-bit symmetric key. NIST says they should be good enough until around 2030.

3072-bit RSA keys offer the same strength as a 128-bit symmetric key. A whopping 15,360-bit RSA key would be needed for 256-bit security; the same level of security could be achieved with a 512-bit elliptic curve key, which would be much, much faster than such a large RSA key.

Re:So 1024 Bits Not Enough Now?

[leathered]

I was thinking the same, and I'm no expert in cryptography. After all distributed.net have spent 12 years trying to brute-force a 72-bit key and have only managed to test 3% of the total keys. 2^1024 is such a mind-bogglingly large number the entire world's computers couldn't crack it in a billion lifetimes.

Anyway, wiki to the rescue:

As of 2003 RSA Security claims that 1024-bit RSA keys are equivalent in strength to 80-bit symmetric keys, 2048-bit RSA keys to 112-bit symmetric keys and 3072-bit RSA keys to 128-bit symmetric keys. RSA claims that 1024-bit keys are likely to become crackable some time between 2006 and 2010 and that 2048-bit keys are sufficient until 2030. An RSA key length of 3072 bits should be used if security is required beyond 2030.[6] NIST key management guidelines further suggest that 15360-bit RSA keys are equivalent in strength to 256-bit symmetric keys.

Re:So 1024 Bits Not Enough Now?

[93 Escort Wagon]

... the same level of security could be achieved with a 512-bit elliptic curve key, which would be much, much faster than such a large RSA key.

It'd be faster for the NSA too - it's a win-win!

Re:So 1024 Bits Not Enough Now?

[dkf]

You're confusing the cost of legitimate operations with the cost of searching the key space. You don't want legit users to bear too much cost since everyone ends up paying that over and over, but you do want the cost of searching to be high since that's not something that people should be doing.

Re:So 1024 Bits Not Enough Now?

[Anonymous Coward]

... the same level of security could be achieved with a 512-bit elliptic curve key, which would be much, much faster than such a large RSA key.

It'd be faster for the NSA too - it's a win-win!

If you are using NIST compliant crypto it doesn't matter anyway. The constraints (supplied by NSA staffers) hint that they know the secret to generate them. As you need to follow the standard to communicate with the US government they can read all that stuff already. Using the elliptic curve without the constraints is most likely safe, but you aren't allowed to use it during communications with your gov and people are not inclined to make a separate crypto setting just for use with the government.

And of those trusted

[Mister Liberty]

you'll never know how many you can't trust.

Will it throw a warning?

[Anonymous Coward]

Are sites that are "untrusted" because they have a weak certificate going to throw up certificate warnings, or just appear the same way as non-authenticated sites?

Connecting to a regular old http site triggers no warning at all. I can understand that we might not want to extend weak certificates the same level of trust as strong certificates, but it would be strange to treat a weak-but-otherwise-valid certificate as somehow less trustworthy than no certificate at all.

Math.

[msauve]

"Grouping those 107,000-plus sites by certificate expiration date, the results show that 76,185 certificates had expired as of Aug. 25"

So, the headline should really say 31,000, since 76,000 shouldn't be trusted regardless of what Mozilla does.

Re:Math.

[afidel]

It's much more important than the 31k affected sites, 1024 roots are weak enough targets that just about any nation state and many crime syndicates can create a flood of valid and trusted certs just by factoring the private key of that one CA cert.

Re:Math.

[msauve]

"It's much more important than the 31k affected sites"

If there are only 31K affected sites, how can it be "more important" than that? The rationalization you give only applies to sites with 1024 roots, which has been stipulated to be those 31K. Where's the "more?"

Re:Math.

[Anonymous Coward]

A nation state or crime syndicate factoring the private key of one of those CAs and creating illegitimate, but valid, certificates for other sites.

You know who I don't trust?

[fyngyrz]

Anyone but self-signed Certificate providers.

All certs effectively do is provide encryption. The whole "provides identity" thing is a myth because there is *no* way to ensure such a thing. There's about a zillion ways to fake that identity. Encryption is guaranteed. Unbreakable encryption is not. That's all you get. That's all you'll *ever* get.

Browser "trust" warnings are nothing more than scare tactics designed by the cert manufacturers, in collusion with browser manufacturers, designed to build a completely unnecessary industry for scamming web site owners out of a huge amount of completely wasted money. Wasted other than funding the cert provider parasites, that is.

Re:You know who I don't trust?

[Charliemopps]

Anyone but self-signed Certificate providers.

All certs effectively do is provide encryption. The whole "provides identity" thing is a myth because there is *no* way to ensure such a thing. There's about a zillion ways to fake that identity. Encryption is guaranteed. Unbreakable encryption is not. That's all you get. That's all you'll *ever* get.

Browser "trust" warnings are nothing more than scare tactics designed by the cert manufacturers, in collusion with browser manufacturers, designed to build a completely unnecessary industry for scamming web site owners out of a huge amount of completely wasted money. Wasted other than funding the cert provider parasites, that is.

Using your reasoning, I could very well be living my life in an NSA created virtual world, so any conversation I have in any capacity at all could be monitored at any time. Even my thoughts! So there is no reason for any of this security what-so-ever and it's all a scam by evil virtual corporations to steel my fake virtual money. Right?

Re:You know who I don't trust?

[NotInHere]

Without identity, you don't know if its the NSA, your ISP, or the actual site you want to talk to you encrypt with. Without cert warnings an ssl connection is almost as good as no one. Active MITM is not very hard if you already intercept all traffic, and you have a small industry that sells appliance cryptobreaking solutions.

It might be true that certs are overpriced in some cases. But that's what a free market is for. The current highly centralized approach makes high centralisation of security neccessary.

The current approach of "one CA signs", everyone trusts is a bad idea. The security is as good as the security of the worst CA. Let certs be signed by multiple CAs. Then the security of the most secure CAs involved counts.
Or, try DANE. It enables TLD owners and IANA to fake you, but at least it requires server owners to publish their cert lists with a timeframe they want to use them in.

Re: You know who I don't trust?

[Anonymous Coward]

I think those sites were already untrusted, if they were still perpetuating insecure ciphers. Certs renew usually every 2 years, and it has been recommended to steer clear of 1024-bit a lot longer than that. They chose to ignore the recommended bit level.

Re:You know who I don't trust?

[the_Bionic_lemming]

try being in business and signing your own cert.

Let me know how many tech calls you get because Norton deletes your web delivered exe.

scare or not - It's a money problem unfairly placed on developers.

Re:You know who I don't trust?

[sjames]

While GP's statement was over the top, it isn't ENTIRELY off base. Lets consider, you connect to a site via. https and look at the cert.

According to the cert, ajaxco says the site is example.com (as expected). But wait, who the hell is ajaxco? Ever heard of them? Any idea how quality oriented they are? How do they KNOW example.com is the one and only example.com? Did they send an investigator? Did they do a corporate records search (for a personal web site, yeah sure)? Or did they make the person who requested the cert pinkie swear?

For all you know, ajaxco, a division of fly-by-night industries gave the cert to the owner's brother-in-law with no concern for correctness whatsoever.

Or perhaps the CA means to be legit but failed to secure their signing key (it HAS happened) and the cert was actually signed by none other than the Russian Mafia.

Perhaps a government somewhere ordered a CA in their jurisdiction to sign the bogus cert. That government may or may not be corrupt.

But you have the ILLUSION that you know who you are talking to.

As for the costs, the market has had 20 years to work that out and it has failed.

Meh!

[Anonymous Coward]

So basically the net effect will be another warning page to click through when visiting the sites in question? Do end users really know what any of this stuff really menas?

And I care about this why ??

[UnknownSoldier]

Seriously, how does this effect web browsing for the average Joe?

Re:And I care about this why ??

[Nimey]

If you visit an affected website in Firefox 32+ it'll warn you about the SSL certificate and you'll have to take a couple extra steps to visit it. For you it's an inconvenience, but only if you use one of these sites. For the website operator maybe it'll shame them into getting an updated certificate.

Unable to add exception (w/ workaround)

[Anonymous Coward]

Your local FreeNAS - like every self-signed appliance with https - will fail with the new Firefox: you'll need to go to about:config and change "accessibility.typeaheadfind.flashBar" to "false" in order to access those appliances.

It does not look like is a single bug, actually:

https://bugzilla.mozilla.org/show_bug.cgi?id=990603

Re:Unable to add exception (w/ workaround)

[Anonymous Coward]

Sorry, cut/paste typo: the flag is actually "security.use_mozillapkix_verification"

Re:Unable to add exception (w/ workaround)

[IonOtter]

Is this alteration specific to self-signed appliances, like a NAS? Or would this bypass for all self-signed certificates?

Also, this sounds like a good thing to keep a record of, with regards to documenting changes in your about:config.

Exaggerated, somewhat hysterical decision

[Anonymous Coward]

RSA-1024 are still safe, despite what many fearmongers have been preaching for years. It was only a few days ago
(http://www.newscientist.com/article/dn26135-factorisation-factory-smashes-numbercracking-record.html?cmpid=RSS|NSNS|2012-GLOBAL|online-
news#.VAXRfDzYvyF) that a new factorization record was announced. It is a roughly 1,024-bit integer - but it took 2000 high end-PC years, and it is a Mersenne integer - orders of magnitude easier to factorize than an integer of similar size obtained as the product of two large primes, which is what one does in the RSA algorithm.

Short of sudden, unexpected and dramatic breakthroughs in the fields of mathematical integer factorization, or quantum computing, RSA-1024 keys still have quite a few years of usefulness ahead.

Re:Exaggerated, somewhat hysterical decision

[Dahan]

Who cares how many "high end-PC years" it took? Nobody's going to try to factor a 1024-bit modulus using a single high-end PC. It took 4 actual years to factor 10 numbers. And why do you think someone who wants to factor the RSA modulus for a 1024-bit CA cert would have waited until today to start the process? Those certs have been around for over 10 years; if someone with enough computing power wanted to factor one, they could be done by now.

Comment removed

[account_deleted]

Comment removed based on user account deletion

So?

[Anonymous Coward]

A pittance. A trifle. They need to get with the times. Period.

The way firefox manages this...

[Anonymous Coward]

And that's probably why they don't, captcha prorate

They declared that security required, https

[raymorris]

The sites got certificates and installed them several years ago, before thw current "https everywhere " trend. In other words, they decided that because they were handling sensitive information, they needed a secure connection. Maybe they have an order form,that accepts credit cards, whatever. For some reason, they needed to be more secured than most sites. The URL in the address bar says "https", indicating that it is secured. We know that although they publicly declared that their site should be secured, it isn't.

Contrast xkcd.com. Randall didn't get a certificate, because you don't need a secured connection to look at nerd comics. Which site presents a security risk? The site that has no need of tls, or the site that needs to be secured, but isn't?

* xkcd might actually have a cert, if they sell stuff on the site or whatever. I didn't bother checking because it's beside the point whether that specific site uses a cert.

Re:They declared that security required, https

[WuphonsReach]

Even if you don't do financial transactions on your site - consumers / customers / users are getting more savvy and want *any* personal information to be encrypted in transit. Login details are naturally something that should always be encrypted, but that also extends to things as mundane as URL history or search terms.

I just wish DANE was farther along (plus DNSSEC).

Maybe those sites need to get in the game

[Anonymous Coward]

Seems to me this article is biased against Mozilla when in fact I think its the lame sites who fail at obtaining the certificates. The average user probably will never encounter this anyway. I take it as a step to securing Firefox better which is a good thing and those 107 thousand sites could most likely fix this issue rather then having Mozilla simply ignore it.

Good!!!

[LostMyBeaver]

Remember that the exponential math in DH and RSA is called a HARD problem, not and impossible one. Consider that regarding key strength 1024 bits of RSA is not very secure in today's world. I'm not saying it's cracked... Just weak.

SSH

[Anonymous Coward]

Does this mean the default 1024-bit SSH key length is too short?

I'm disappointed

[Anonymous Coward]

that beta.slashdot.org wasn't affected by this.

Re:I'm disappointed

[Anonymous Coward]

beta could suck my dick !

Seems kind of pointless- the DNS has to be subver

[raymorris]

DANE seems very nearly pointless to me. Maybe I'm mising something. The victim goes to Paypal.com. Their browser checks the certificate to make sure it's really Paypal.com, as opposed to a MITM or someone who hijacked Paypal's DNS. That's the typical use for TLS, right?

So checking the cert is supposed to protect the user from an adversary who can intercept packets addressed to Paypal.com and send back bogus responses. That means the adversary can intercept DNS packets intended for Paypal.com and respond wuth a bogus cert record. Nothing has been gained unless you can independently verify the DNS records using some other mechanism. It's proposed that DNSSEC be used for this. DNSSEC basically means the DNS record is signed, so to trust the DNS we need to validate the cert used to sign the DNS. Okay, soall we have to do is find a way to validate a DNS signing cert. If we can validate that cert, we can trust the ssl cert.

Hmm, we validate someone's cert by first validating their cert? I don't think we've made any progress toward solving the problem.

Re:Seems kind of pointless- the DNS has to be subv

[WuphonsReach]

DANE is mostly to guard against rogue CAs. CA #1 cannot sign a certificate claiming to represent the domain that was actually certified by CA #2. So it limits the amount of damage that a rogue CA can get away with.

It may also eliminate the need for CAs and certificate altogether. You just store the public half of your certs in the DNS system.

Re:Seems kind of pointless- the DNS has to be subv

[raymorris]

-> It may also eliminate the need for CAs and certificate altogether. You just store the public half of your certs in the DNS system

That's the problem. By the time a TLS certificate comes into play, the DNS must have already been compromised (directly or via mitm). The certificate is designed to alert you if the server you're talking to isn't who you think it is - based on DNS.