×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

22 Million SSL Certificates In Use Are Invalid

kdawson posted more than 3 years ago | from the netcraft-confirms-it dept.

Security 269

darthcamaro writes "While SSL certs are widely used on the Internet today, a new study from Qualys, set to be officially released at Black Hat in July, is going to show some shocking statistics. Among the findings in the study is that only 3% of SSL certs in use were actually properly configured. Quoting: '"So we have about 22 million SSL servers with certificates that are completely invalid because they do not match the domain name on which they reside," Ivan Ristic, director of engineering at Qualys, said.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

269 comments

Two reasons for SSL (4, Insightful)

EconomyGuy (179008) | more than 3 years ago | (#32725474)

Two reasons for SSL: verification and encryption. Sure, if the domains don't match you don't have verification, but the communication is still encrypted, and if you happen to control both ends of the exchange, that's all you need.

Re:Two reasons for SSL (4, Insightful)

marcansoft (727665) | more than 3 years ago | (#32725492)

Unfortunately, all the browser vendors decided to implement this backwards and instead throw around ridiculously alarming warnings at the user if you dare use SSL for encryption only, and not verification.

You know, instead of the sane thing, just dropping the lock icon or otherwise indicating diminished (but not nonexistent security). Find that a non-expiring cert changes or a page with a verified SSL cert suddenly has a non-verified SSL cert? Then scare the living hell out of the user.

Re:Two reasons for SSL (5, Insightful)

Deorus (811828) | more than 3 years ago | (#32725574)

The worst is when they even force users to add exceptions just to watch random websites (Firefox, I'm looking at you). Now not only do I have to deal with the annoying warning blown out of all imaginary proportions, but I'm also adding an exception to a random website just because I want to browse it once in a life time that I may never remember to remove in the future and may cause real security issues later.

I really can't understand what's so wrong with temporary exceptions...

Re:Two reasons for SSL (5, Informative)

Anonymous Coward | more than 3 years ago | (#32725738)

Even better when (yes, Firefox again!) the exception you are required to add ALSO changes the security mode used for Javascript! Sites you add exceptions for run as a Trusted Site and have elevated privileges.

Re:Two reasons for SSL (4, Informative)

apparently (756613) | more than 3 years ago | (#32725794)

The worst is when they even force users to add exceptions just to watch random websites (Firefox, I'm looking at you). Now not only do I have to deal with the annoying warning blown out of all imaginary proportions, but I'm also adding an exception to a random website just because I want to browse it once in a life time that I may never remember to remove in the future and may cause real security issues later.
I really can't understand what's so wrong with temporary exceptions...

Firefox allows you to make temporary exceptions; you're just not doing it. When you click on the "Add an exception" button, followed by the "Get Certificate" button, there's a checkbox with the text "Permanently store this exception". Guess what happens if you leave that box unchecked and click the "Confirm Exception" box? A temporary exception is made.

Re:Two reasons for SSL (0)

Anonymous Coward | more than 3 years ago | (#32725902)

Right, so after telling you how terrible it is to accept the certificate, Firefox has permanently storing the exception as the default...

Re:Two reasons for SSL (5, Informative)

mysidia (191772) | more than 3 years ago | (#32726064)

Actually it's checked by default, when you click 'get certificate'

And many times i've found after unchecking the box and going to hit the 'Confirm' button... it rechecks just after hitting confirm, and closes the window with a permanent exception added, despite my attempt to only add a temporary one.... very annoying Firefox...

Re:Two reasons for SSL (3, Insightful)

forkazoo (138186) | more than 3 years ago | (#32726050)

Firefox allows you to make temporary exceptions; you're just not doing it. When you click on the "Add an exception" button, followed by the "Get Certificate" button, there's a checkbox with the text "Permanently store this exception". Guess what happens if you leave that box unchecked and click the "Confirm Exception" box? A temporary exception is made.

It is technically possible, but when it is hidden behind so much terrible UI, it barely matters that the feature technically exists. Most users would rather have their identity stolen than have to wade through that mess. Frankly, losing all of your money, and spending years sorting out the consequences of identity theft is a lot more convenient than the Firefox cert warning UI.

Re:Two reasons for SSL (5, Interesting)

dwillden (521345) | more than 3 years ago | (#32726124)

No the worst is trying to use a military computer (means only IE) to hit military sites, and having to approve half a dozen exceptions each time you visit a new page.

They seem to be unable to use standard certificates or even attempt to register them with internet registries. The best is working on a classified network. And getting "WARNING!!! This page may be unsafe! WARNING!!!" notices on an entirely closed and encrypted network.

Re:Two reasons for SSL (4, Insightful)

no-body (127863) | more than 3 years ago | (#32725838)

It's a money making scheme - if you look at the "fees" one has to shell out for certificates - has absolutely nothing to do with effort necessary to provide a certificate.

Part of the great pyramid where all the money is rising upwards to a small top, partially fueled by the - is it the dripping down - or trickling down - fantasy.

Verisign must have severely lobbied (greased) the browser vendors...

Certs should be issued by the government, like passports - for a reasonable fee. Probably a dud in US where free market rules with great results as one more and more can see.

Re:Two reasons for SSL (3, Interesting)

mysidia (191772) | more than 3 years ago | (#32726080)

Yes... it was a total disaster... fortunately, in the future DNSSEC should make SSL certificates obsolete.

If we can publish digitally signed records in the DNS, which are verifiable with the registrar, it's not too farfetched to say define a signed TXT record which will contain public key information for the web server.

Re:Two reasons for SSL (1)

spongman (182339) | more than 3 years ago | (#32726300)

simple SSL/S.MIME certs can had be had here http://www.startssl.com/ [startssl.com]. i'm not affiliated with them, but i have gotten a few certs from them. you can't beat the price, and their support is timely and helpful. you have to pay for more advanced certs like multiple names, wildcard, etc...

Re:Two reasons for SSL (2)

0123456 (636235) | more than 3 years ago | (#32726256)

Unfortunately, all the browser vendors decided to implement this backwards and instead throw around ridiculously alarming warnings at the user if you dare use SSL for encryption only, and not verification.

There is nothing at all insightful about that post. If I go to connect to www.mybank.com and instead my connection is hijacked to xyz123.fubar.ru then I sure as hell want my web browser to scream and shout that the connection is invalid.

Not having my banking logon details stolen is a metric fsckload more important than people being able to log on to uncertified sites without adding an exception.

Re:Two reasons for SSL (3, Insightful)

marcansoft (727665) | more than 3 years ago | (#32726512)

If you connect to your bank through HTTP (and aren't redirected), nothing will save you from an attacker stealing your bank details unless you notice the lack of a lock icon indicating an SSL connection. This is exceedingly likely if, say, Joe Average user just types www.bank.com in his address bar and an attacker hijacks his connection and replaces the usual redirect to HTTPS with a man-in-the-middle attack on the bank.

Therefore, it makes zero sense to throw huge warnings for untrusted certs and yet do nothing for plain old unencrypted HTTP.

The only sane way to implement SSL warnings is to use memory. This gives you increased security (why did ChinaSSL suddenly start providing my bank's certificate? Right now, if that happens, you're 100% screwed) and avoids annoyances (no huge four-click warnings if you visit a site for the first time and its certificate is not verified by a CA).

Right now we're in the ridiculous situation where the least secure connection (HTTP) is given preferential treatment over the somewhat secure connection (unverified HTTPS), and yet the most secure connection (verified HTTPS) is both less secure than it could be (no sanity checks, if any CA signed it then it's good) and can be trivially downgraded to insecure HTTP, depending on the user's browsing habits.

This nonsense prevents widespread adoption of HTTPS for personal and noncritical sites. If browsers shipped with something like Certificate Patrol (tweaked for user usability instead of paranoia, avoiding dialogs during "normal" situations) and ditched the stupid warnings for untrusted SSL certificates (if they've never been seen using a trusted cert) it would go a long way towards encouraging the use of HTTPS and the Web would be a much safer place as a result.

Right now, if you go connect to www.mybank.com (which defaults to HTTP) and your connection is hijacked, unless you notice the lack of a lock icon, you're screwed. This is no worse than having an unverified SSL cert served and having the browser not display the lock icon as a result. It's definitely worse than the proper implementation, where the browser would warn you of an unencrypted connection that's usually encrypted, or having an unverified SSL connection that was previously seen as verified.

Re:Two reasons for SSL (2, Insightful)

QuantumG (50515) | more than 3 years ago | (#32725500)

So you want defense against snooping but don't care about defense against MITM attacks. Fair enough, I'm all for raising the bar, but don't be lured into thinking your communication is secure.

Re:Two reasons for SSL (1)

phantomfive (622387) | more than 3 years ago | (#32725570)

I think a lot of times it is a matter of people not wanting to pay to get their cert signed. The threat of MITM is low enough (for them) that they don't care (and frankly for a lot of them the risk of a PHP exploit is truly more likely). Or in this case, it could be there are a lot of personal web servers that were just set up and happened to have https turned on, without them really caring too much about it.

Re:Two reasons for SSL (5, Informative)

seifried (12921) | more than 3 years ago | (#32725632)

Invalid argument: Free SSL certificates: http://cert.startcom.org/ [startcom.org].

Re:Two reasons for SSL (2, Insightful)

bunratty (545641) | more than 3 years ago | (#32725804)

The last I checked, startcom certificates are not recognized as valid by Firefox. I purchased a five-year certificate from rapidssl.com for $60 a few years ago, and the certificate is recognized as valid by all major browsers. The cost is minimal.

Re:Two reasons for SSL (2, Interesting)

dgatwood (11270) | more than 3 years ago | (#32725882)

They've been supported for a while now, at least in Mac OS X. (I qualify that because I'm not 100% sure they don't pull in the OS's trusted roots.) Point Firefox at https://www.gatwood.net/ [gatwood.net] if you want to confirm it for yourself.

Re:Two reasons for SSL (3, Informative)

seifried (12921) | more than 3 years ago | (#32725984)

You need to install the intermediate Startcom SSL certificate on your web server but that is easy and extensively covered in the documents. Again, there is NO excuse.

Re:Two reasons for SSL (1)

SpazmodeusG (1334705) | more than 3 years ago | (#32726022)

You may as well just self sign if you are going to use a certificate that isn't in the root keys of any major OS

Re:Two reasons for SSL (1)

spongman (182339) | more than 3 years ago | (#32726340)

the startcom root cert has been distributed by browser vendors for a while now. eg: it was shipped via Windows Update in Sept/2009

Re:Two reasons for SSL (3, Interesting)

marcansoft (727665) | more than 3 years ago | (#32725606)

It's considerably secure if your browser caches the certificate and puts up a warning if it changes. Then you need to be MITMed on your first visit for it to be effective, and then it has to keep up or you'll notice.

This is how SSH verification works, and I don't see many people getting MITMed, even if you don't usually check the fingerprints.

Re:Two reasons for SSL (1)

QuantumG (50515) | more than 3 years ago | (#32725654)

Umm.. I'm not aware of any browser that will warn you of a changed certificate if the cert is signed by a valid authority. So if I can convince the drooling morons at the SSL cert authority to give me a cert for your domain, the game is over.

Re:Two reasons for SSL (3, Insightful)

marcansoft (727665) | more than 3 years ago | (#32725758)

The Certificate Patrol extension for Firefox will. It'll tell you when a certificate changes and whether it should (e.g. whether it was near its expiration, and whether the issuer has changed).

Re:Two reasons for SSL (1)

TheLink (130905) | more than 3 years ago | (#32725760)

There's at least one firefox plugin (Certificate Patrol) which may help (it does trust some CAs a bit more than others but I guess you can modify it if you want).

The morons are the ones making the browsers - since the current browser architecture requires you to trust ALL CAs that are installed in your browser for ALL possible sites. This issue has been known for years but they refuse to fix it.

So if some Randomistan CA signs yourbank.us it's treated as valid even if the old cert was valid for years and was signed by some other CA.

Re:Two reasons for SSL (1)

icebraining (1313345) | more than 3 years ago | (#32726042)

Then delete the certs from CAs you don't trust: Preferences -> Advanced -> Encryption -> View Certificates -> Authorities -> Select the one you don't like -> Delete.

There, any cert that's signed by that CA will show an invalid certificate error.

Re:Two reasons for SSL (1)

TheLink (130905) | more than 3 years ago | (#32726384)

Fact is I don't trust any of the CAs. So I have long removed all CA certs from one of my browsers (I use more than one browser for security and other reasons, and my browsers don't all run as the same user - so if some exploit gets one browser, it's harder for it to affect the other browser instances).

You seem to think it's so simple, let me ask you this: do you have Entrust's certs in your browser? Do you trust CNNIC? Entrust has signed at least one of CNNIC's _CA_ certs[1].

I may trust the website I'm dealing with (I have to), so if the first time I use that site, if I can lock on to that cert "forever", my actual risk exposure is quite low. If that site gets pwned, whether or not the certs get pwned doesn't matter since the _site_ is pwned. The problem is most certificates expire after a very short time.

And the main problem is the CAs are a bigger security risk than "someone happening to MITM me at just the first time". Really what are the odds? The CAs have signed the wrong certs before.

The site getting pwned is also a risk, but you have to accept that if you deal with that site anyway.

In some cases Governments are a bigger threat than some random hacker.

[1] http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/7ba51ca49de0f6cf/82ae68bc8d4292f8?show_docid=82ae68bc8d4292f8# [google.com]

Re:Two reasons for SSL (1)

mysidia (191772) | more than 3 years ago | (#32726116)

The morons are the ones making the browsers - since the current browser architecture requires you to trust ALL CAs that are installed in your browser for ALL possible sites. This issue has been known for years but they refuse to fix it.

Yet another use case for DNSSEC. :)

Re:Two reasons for SSL (1)

TheLink (130905) | more than 3 years ago | (#32726248)

How's DNSSEC going to help?

You really think websites are going to have the same ssl certs as those fetched from DNS servers? In practice I doubt that's ever going to happen.

And if the browser bunch haven't even fixed the problem I'm talking about after 5 years, I doubt they'll find a way to use DNSSEC to actually make things more secure.

Re:Two reasons for SSL (1)

icebraining (1313345) | more than 3 years ago | (#32725792)

Can you? Convince them, I mean?

Re:Two reasons for SSL (1)

QuantumG (50515) | more than 3 years ago | (#32725826)

Yup, there's so many of them that only want your credit card number and will sell you just about any domain except maybe Microsoft.com or Facebook, etc.

Re:Two reasons for SSL (3, Insightful)

LordKronos (470910) | more than 3 years ago | (#32725610)

So you want defense against snooping but don't care about defense against MITM attacks.

Yes, that's exactly what I want as the minimum requirement. Snooping on traffic is incredibly simple to do, and can really be done easily by anyone at any point along connection path. You just start up a packet sniffer, grab random packets, and wait until you catch something interesting. You don't even have to catch an entire session. Successfully pulling off a MITM attack is MUCH more complicated...requiring something trickier, such as hijacking DNS. You can't just be at any random point along the chain and perform the attack on any random connection coming through.

It's like a lock on my front door. I don't delude myself into thinking that nobody can get into my house, but the lock is a safeguard against the easiest attack vector.

Re:Two reasons for SSL (3, Informative)

QuantumG (50515) | more than 3 years ago | (#32725696)

Your view of both sniffing and TCP hijacking seems to come from the mid-90s. I recommend reading up on both the improvements of switched networking and on the active techniques developed to defeat them. But yes, MITM is harder to get right, just as these techniques were harder to develop than just turning the network adapter to promiscuous mode.. but once they're developed, it's just a tool that anyone (or bot) can wield.. and they have been already.

Re:Two reasons for SSL (2)

complete loony (663508) | more than 3 years ago | (#32726092)

Lots of ISP's already run a transparent proxy to redirect port 80 traffic through their cache. Adding a MITM SSL proxy to this setup would be trivial if all clients blindly trusted the connection.

Re:Two reasons for SSL (1)

gumbi west (610122) | more than 3 years ago | (#32725684)

Sometimes, but other times no. Examples: a connection that never leaves my subnet, if someone can launch a MITM on my network, I'm so much more screwed than I thought I should just give up in the first place. OR, a connection that I first initiate on a shared network, store the exception and THEN make remotely. OR, a connection that I verify the signature for over the phone.

Re:Two reasons for SSL (1)

QuantumG (50515) | more than 3 years ago | (#32725734)

Umm.. if they can sniff unencrypted traffic on your subnet then you're screwed too right?

Re:Two reasons for SSL (1)

DragonWriter (970822) | more than 3 years ago | (#32725774)

So you want defense against snooping but don't care about defense against MITM attacks. Fair enough, I'm all for raising the bar, but don't be lured into thinking your communication is secure.

Even against snooping, since that's exactly what an MITM attack is.

Re:Two reasons for SSL (2, Insightful)

izomiac (815208) | more than 3 years ago | (#32725802)

Most people couldn't even tell you who the trusted certificate authorities were on their browser. From there, I'd say the number of users who personally trust all of them approaches zero. Knowing that you're connecting to the same entity on every connection would prevent most MITM attacks.

Of course, ideally, we'd verify the certificates over physical means. Until there's an easy way to do that you always run the risk of connecting to an impostor. OTOH, people are happy to give money to a random company (e.g. VeriSign) that promises security without requiring any change in behavior.

Re:Two reasons for SSL (1)

lewis2 (212695) | more than 3 years ago | (#32725578)

Yes and if the guy on the other end is a proxy server by whomever you're afraid of (criminals, good guys, mommy) then no need for the encryption part either.

Re:Two reasons for SSL (1)

jamesh (87723) | more than 3 years ago | (#32725664)

Two reasons for SSL: verification and encryption. Sure, if the domains don't match you don't have verification, but the communication is still encrypted, and if you happen to control both ends of the exchange, that's all you need.

IMHO, that's a fail. If your users are trained to just click through certificate exception errors then all someone needs to do is intercept your dns or otherwise subvert your dns lookups and when your users go to www.mybank.com but end up at the bad guys site they won't know the difference and you'll be giving the bad guys your credentials (over an encrypted stream - woohoo!)

If you control both ends of the exchange (eg a corporate intranet) then use a self signed cert and give your users the CA public key via a secure means, but make sure that everything else is correct. IMHO, if done right this is even more secure as no 'trusted' third party is involved, but it doesn't scale up to publicly accessible websites.

Re:Two reasons for SSL (1)

TheLink (130905) | more than 3 years ago | (#32725884)

> and give your users the CA public key via a secure means,

If you're talking about browsers, you have to remove/disable the other CAs from your users browsers/OSes.

Otherwise those CAs can provide valid certs for your sites (or for other CAs!). Whether knowingly/complicitly or unwittingly.

If you are unwilling/unable to remove those CAs you need a browser that can warn or prevent access if server certs are signed by wrong/unexpected CAs.

Otherwise things aren't really that secure.

Do you really trust some CA in China that's probably an arm of the Chinese Government? And if some CA in the USA signs that Chinese CA's "CA certs" too, as long as your browser trusts that US CA's certs, the Chinese CA's certs are in your chain of trust whether you know it or not see:

http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/eea04805fbd98045#87b9eab77242b4af [google.com]

http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/7ba51ca49de0f6cf/82ae68bc8d4292f8?show_docid=82ae68bc8d4292f8 [google.com]

Too bad the browser makers don't really care about security, despite this being a known problem for years you still need a firefox plugin to deal with this.

Re:Two reasons for SSL (4, Insightful)

DragonWriter (970822) | more than 3 years ago | (#32725768)

Two reasons for SSL: verification and encryption. Sure, if the domains don't match you don't have verification, but the communication is still encrypted, and if you happen to control both ends of the exchange, that's all you need.

If you don't control the whole path between (in which case, you probably don't need encryption), the absence of verification renders encryption pointless.

If you control both ends, there is no reason not use valid certificates (both matching the domain and signed by a CA -- your own, if nothing else).

Invalid certificates of the type at issue (not matching the domain) usually mean you've bought a certificate from a commercial CA, and are using it on a domain other than the one you've bought it for, possibly because you have different domains that resolve to the same address (domains with and without "www." prefix where both use the same certificate that is intended to have the "www." prefix are the most common ones I've personally encountered on the web.)

Mod parent up (2, Informative)

AusIV (950840) | more than 3 years ago | (#32726040)

Encryption without authentication is pointless. There are readily available tools that will allow a script kiddie to man-in-the-middle SSL communication with just a few clicks. This can be done from the same wireless network, physical network, or at any node between the source and destination hosts. Encryption without authentication is nothing but a false sense of security.

Re:Mod parent up (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32726514)

Encryption without authentication is not pointless. Encryption stops passive third parties from listening in. Maybe you're not talking to the entity you thought you were talking to without verification, but at least only the party on the other end can read your message.

I don't think this kind of connection should be represented by the lock or the colored bar or anything like that, but it's foolish to say there are no advantages over totally unencrypted traffic in these days when our ISPs sell our personal data and governments are increasingly monitoring Internet traffic.

Why can't the browser just encrypt things and make no claims about identity verification? Whatever the reason, it smells really fishy.

encryption, not trust (1)

Michael Kristopeit (1751814) | more than 3 years ago | (#32725484)

that's because SSL, even misconfigured SSL, provides a layer of encryption to thwart network packet sniffing... most people don't care about the potential for SSL to establish a higher degree of "trust"... they just want encryption.

Re:encryption, not trust (0)

Anonymous Coward | more than 3 years ago | (#32725636)

using a multi step login process over SSL using an invalid certificate, where the user is presented with pre-answered challenge questions, and then presented with their predefined message/image to establish "trust" before the login credentials are sent effectively mimics the protection of trusting a 3rd party to validate the SSL certificate as authentic.

realistically there will always be potential for a MITM attack... it's just about how big the middle is, and how well it is protected.

Re:encryption, not trust (1)

Dan9999 (679463) | more than 3 years ago | (#32725788)

well I can answer how big the middle is... how big is this internet called the Internet that I have between me and my site? And if you know that then you could probably tell me just about how protected it is too... here's a link that may help find some preliminary info:

http://tech.slashdot.org/story/10/06/28/2340237/22-Million-SSL-Certificates-In-Use-Are-Invalid?art_pos=1 [slashdot.org]

Cheers

Re:encryption, not trust (1)

Michael Kristopeit (1751814) | more than 3 years ago | (#32725850)

well, when you use a shared 3rd party to establish trust, the middle becomes only as big as the 3rd party's local network... but there are still 2 separate connections to the 3rd party... if they were both middled simultaneously the trust of the 3rd party is irrelevant. it's all just 1 more degree of difficulty.

Re:encryption, not trust (1)

ToasterMonkey (467067) | more than 3 years ago | (#32725712)

You're all wrong, encryption is NOTHING without trust! There is no point in encrypting your communication with [UNKNOWN], because they could be anyone, and even relay your message to [UNKNOWNS].
You're not encrypting your session from A to B in this case, you're encrypting your session from A to (B) CLOUD.

most people don't care about the potential for SSL to establish a higher degree of "trust"

Uh, the more trust the better. It is not black and white. The average consumer is always going to have to trust their PC/OS manufacturer/reseller doesn't dick with the root keys, because they will not ever physically exchange keys, or care to regularly change them. The assumption is that the keys provided on the machine are good, and future delivered keys will be good, without EVER even looking at the fingerprints.

A mismatched URL isn't the end of the road, it's just an indicator that the SSL cert may have been stolen. Since you just have to assume that the certificate was issued to "Company Name" when the CA says so (that is their real job), you could do what they do and verify that "Company Name" in the certificate owns the DNS registration of the URL in question. That's as much as a CA is going to do anyway, but they want to sell that service to the site's maintainers very badly, so don't expect to have to do that very often. Just gloss right over the levels of trust and sell you a pretty green bar.

Re:encryption, not trust (1)

marcansoft (727665) | more than 3 years ago | (#32725808)

You're all wrong, encryption is NOTHING without trust! There is no point in encrypting your communication with [UNKNOWN]

Yes there is, if the chances of a third party sniffing your connection are higher than the chances of a third party breaking into your connection. Your argument only holds if you view the path between you and the server as a homogeneously insecure cloud. This isn't how real world networks work. Encryption alone does provide increased security over most networks, though it may not provide a security guarantee.

Re:encryption, not trust (1)

EvanED (569694) | more than 3 years ago | (#32725968)

I find it amusing that you say "There is no point in encrypting your communication with [UNKNOWN]" and then go on to say "Uh, the more trust the better. It is not black and white."

But it's precisely because trust isn't black-and-white that there can be a point of encrypting your communication with UNKNOWN. If I trust that carrying out a MITM attack is harder than snooping on unencrypted traffic, then there is a point to encrypting without authentication.

Re:encryption, not trust (1)

edrugtrader (442064) | more than 3 years ago | (#32725972)

save for theoretical quantum encryption, there is always the potential for a MITM attack. ALWAYS.

using a 3rd party is only effective as it is an order of magnitude more difficult to middle both connections simultaneously... theoretically if you could do that, you either have access to sniff the whole internet or the 3rd party's local network or the local networks of both ends... if you already have that level of access, it's already game over. do you trust the tumbler lock on your front door, or do you nail boards over the door and barricade it with a boulder every night?

i have a legal freeware program that sniffs wireless networks to analyze them for quality of service. this will include pieces of unencrypted IP packet data. google recently used similar tools and accidentally obtained sensitive data.

add on top of SSL pre-defined challenge questions, and a message or image defined by the user and presented by the service and you've got the same level of protection as a valid SSL certificate. combining them helps even more, but there are still attack vectors.

I don't need to confirm my own idenity. (1)

LostCluster (625375) | more than 3 years ago | (#32725486)

I use non-conforming SSL all of the time... to get back to my own servers where I don't need to verify organizational integrity, I just want an encryption layer protecting me from snoopers.

Yeah, I'll honor the stop sign if a site asking me for money or access to another account can't verify itself, but why do I need to check my own ID?

Re:I don't need to confirm my own idenity. (2, Informative)

quenda (644621) | more than 3 years ago | (#32725534)

but why do I need to check my own ID?

MiTM attack. e.g. using an internet cafe, which installs a transparent SSL proxy and can monitor all your transactions. Its OK if you have your own browser device, and previously installed your SSL certificate over a secure channel. But if you get the 'stop sign' over an insecure channel, take it seriously. They don't need to clone your server to compromise you, just a man-in-the-middle.

Re:I don't need to confirm my own idenity. (1)

Deorus (811828) | more than 3 years ago | (#32725624)

You can prevent that with public key fingerprinting if you control both end points, which you do assuming you are using your own laptop at the internet cafe. If you aren't using your own laptop, then there's a lot more to worry about than the communication channel.

Re:I don't need to confirm my own idenity. (2, Informative)

TooMuchToDo (882796) | more than 3 years ago | (#32726014)

For that you should be using the Perspectives Firefox Add-on. It checks with several notary signatures if the SSL key looks the same from everywhere. If it doesn't, it flags it.

Duh (5, Interesting)

afidel (530433) | more than 3 years ago | (#32725490)

Virtual hosts mean if you just do an IP scan you will likely run into an SSL site that doesn't match the first URL associated with an IP.

Re:Duh (4, Interesting)

NNKK (218503) | more than 3 years ago | (#32725600)

Virtual hosts mean if you just do an IP scan you will likely run into an SSL site that doesn't match the first URL associated with an IP.

Wish I had mod points. I was about to post the exact same thing.

Even ignoring servers hosting multiple distinct sites (e.g. at a typical webhosting company) on one IP with some sort of management interface behind SSL on port 443, sites are often configured with their "secure" portion behind a different vhost, but the same IP (e.g. http://example.com/ [example.com] may point to the same IP address as https://secure.example.com/ [example.com], but you're still going to get an SSL-secured response from https://example.com/ [example.com], just not the one you might expect).

One can make reasonable arguments that these might not be ideal configurations, but they don't present the serious practical problems implied by the article.

Re:Duh (3, Insightful)

Pharmboy (216950) | more than 3 years ago | (#32725618)

Also, every dedicated server has SSL for logging in (Server Beach, etc.), and the certificate never matches the domain, typically localhost.localdomain or similar. If you aren't doing actual ecommerce, then there is no reason to buy a certificate if you can instead just create one or use the self generated one, and either ignore the warning on your client, or install the certificate on the client as trusted (one mouse click). So to this "poll", it would appear to be incorrect, although it is perfectly fine and secure for the purpose it is being used for.

Re:Duh (3, Interesting)

man_of_mr_e (217855) | more than 3 years ago | (#32725796)

Indeed. I bet there is a very large percentage of these "misconfigured" SSL certs that are in the list for this very reason. Just because you can get to an IP by a given domain name doesn't mean that's the domain it's intended to use SSL with.

Also, think about all the millions of firewalls and routers out there with enabled WAN access and a bogus ssl cert just to make it work. Think of all the development servers, think of all the self-signed certs (which whould show up as invalid to the researchers because they're not configured to accept the self-signed cert).

I would highly doubt any mroe than 20% of those "misconfigured" servers are actually misconfigured ssl certs for real sites.

Re:Duh (1)

Nizzt (45461) | more than 3 years ago | (#32726052)

So I host a server with 50 domains on one IP address, and 5 SSL sites each with there own IP address. Rather then having 6 IP's I share one of them with the same address as the virtual domains. So 50 sites when queried with HTTPS will show the wrong SSL cert, and if some of those virtual domains have wild card hostnames, the number is much higher.

So I would bet the vast majority of the invalid certs are for the wrong host entirely. So for my example 2% are valid, and its only 50 hosts (excluding the other 4 SSL domains).

Re:Duh (0)

Anonymous Coward | more than 3 years ago | (#32726478)

Actually, you can only have one SSL host per IP address. Domain-based virtual hosting doesn't work with SSL because the SSL connection is established before the virtual host name is sent in the Host: request header.

Almost completely useless as a result. (4, Insightful)

Gavin Scott (15916) | more than 3 years ago | (#32725520)

This week I'm helping a customer with some remote testing with a large hosting company who provides remote system console access via a Java/Web thing.

They sent me a PDF with the instructions for logging in that have a couple pages dedicated to telling you how to ignore the fact that all their certificates are expired or simply invalid, and tell you to check the "Always trust content from this publisher" box in order to eliminate the need for one extra click.

How can we ever expect to get any use out of this stuff if we're constantly training the users to ignore everything the security software is trying to tell them?

It seems to be considered completely acceptable behavior by very large well-known companies too.

G.

Re:Almost completely useless as a result. (3, Interesting)

kimvette (919543) | more than 3 years ago | (#32725590)

Why pay for a root-issued certificate when a self-signed one will do perfectly well when it's a known-safe server accessed only by a few authorised users? Just click through the "add exception" or "install certificate" dialog and be done with it.

Re:Almost completely useless as a result. (1)

stanlyb (1839382) | more than 3 years ago | (#32725708)

That's what i use, and it is pretty damn secure. And there is one other problem, what if you wanna to have a 2-way security, and what if one of the computers is with limited connectivity (let say allowed to connect to only some very specific set of servers), in which case you are simply not able to verify the certificate. And man, thank you very much for the good news, i adore Futurama, long live Fry.

Re:Almost completely useless as a result. (1)

bigtrike (904535) | more than 3 years ago | (#32725898)

You don't have to verify the certificate with the signer, that's why browsers come pre-loaded with CA certificates. The only thing that you would need outside access for is to check it against a CRL, but that's not necessary.

Epistemology, bitches! (2, Insightful)

zippthorne (748122) | more than 3 years ago | (#32726106)

It's the distribution, stupid.

A self-signed cert that you just click "accept" for is worthless. It could've been useful, if you'd transferred the cert out-of-band and added it directly to the trusted list, but if you're fetching it off the internet, you've no idea whether the cert you're getting is the real one or not.

CA's are a tool for consolidating the certificate transfer process. Instead of having to manually install every certificate, you really only need to manually install through some trusted process, a single certificate that can sign all the others (presuming you have reason to trust their reasons for trusting)

Of course, nobody does that either, and using the certificates built-into a browser you downloaded insecurely is just as dumb as using self-signed certs off the net without any out-of-band component....

Re:Almost completely useless as a result. (5, Insightful)

Alwin Henseler (640539) | more than 3 years ago | (#32725896)

How can we ever expect to get any use out of this stuff if we're constantly training the users to ignore everything the security software is trying to tell them?

We can't, and we shouldn't. When users regularly see warning messages that are abacadabra to many of those users, the effect is predictable (and well understood): user won't read warnings anymore, and just do whatever is most likely to make the warning disappear.

At that point, you're just wasting user's time, making sure that genuine serious events dive below the radar, and waste system resources / application code (warning dialog boxes, etc) that doesn't get you any real-world gain. Which means that overall, you're doing worse than if you had just silently ignored those warnings.

If you want secure: make it work, solid, and easy to use. If that's too much to ask, better forget about it - a half-baked feeling of security is worse than being aware of its absence.

So an obvious better solution would be to handle invalid/broken security tokens for what they are (non-secure), and don't bother users with it other than small (visible) clues that could be checked by users who care and/or know what they're doing. Eg. expired SSL cert in a browser session -> no warning dialog, show URL like regular URLs in address bar (vs. special markup used for secure connections), and open/no lock icon in status bar.

Re:Almost completely useless as a result. (1)

repetty (260322) | more than 3 years ago | (#32726120)

I worked for a company that used SSL for their primary internal web site but it was composed of content from other unsecured servers. As a result, all the users were getting security warnings from their web browsers. They were using IE 6; other browsers gave more descriptive messages like "mixed content".

IT's response was that it was NOT a security problem. During their next security push they updated IE 6 on their user's machines to ignore the problem.

Re:Almost completely useless as a result. (0)

Anonymous Coward | more than 3 years ago | (#32726444)

OMG my first initial is G. too!!!! What a coincidence!!! What are the odds!!!!

But I'm not a dick who writes G. in the body of all my own posts.

G

Methodology? (4, Informative)

dachshund (300733) | more than 3 years ago | (#32725550)

That number seems high. I've seen many cases where a server is configured both at the correct address (say, www.foobar.com) and at another address which is not embedded in the cert (foobar.com). Depending on how you access the site you'll either get a perfectly valid cert or an invalid certificate message.

While a setup like this is improperly configured, it may not matter that much. If nearly all visitors access the site via the correct domain name, the SSL cert is probably doing its job.

Re:Methodology? (1)

jd (1658) | more than 3 years ago | (#32725634)

I dunno. A lot of sites I visit (like the RTAI real-time Linux site) use mis-configured SSL certs. In the RTAI case, it's bothersome because I don't need encryption but I do like knowing that the file I'm getting is the file I think I'm getting.

No Big Deal (4, Interesting)

harryjohnston (1118069) | more than 3 years ago | (#32725556)

"Only about 3.17 percent of the domain names matched," Ristic said. "So we have about 22 million SSL servers with certificates that are completely invalid because they do not match the domain name on which they reside."

If you think about it, though, all he really knows is that the certificate does not match the domain name he used to connect to the server, which may not be the domain name which is meant to be used. The obvious next step would be to attempt to connect to the name given by the certificate, which might well point to the same actual site. Of course, it might be a name that is only valid for an internal network, not on the internet as a whole.

There are also lots of contexts in which a web server includes a default (usually self-signed) certificate with a generic name out of the box - typically web servers used for management of a software or hardware device. If the users don't need SSL, there's no reason for a "valid" certificate to be installed.

In short, he's using the phrase "in use" poorly; the fact that a server responds to an SSL request with a particular certificate does not mean that the certificate is "in use" in any meaningful way.

(These figures might be more meaningful if he had excluded self-signed and locally-signed certificates, looking only at those generated by a known certificate provider. Because they cost money, the latter are more likely to have been intended for actual use, although the actual use still might use a different URL than the one you are scanning.)

Re:No Big Deal (1)

Thad Zurich (1376269) | more than 3 years ago | (#32726126)

Actually, he appears to be using the phrase "completely invalid" poorly. The certificate proves (to a point) that it was issued to the site using it by the signing authority. THE NAMES DON'T HAVE TO MATCH! Either you trust the signing authority and the fact that the certificate holder has its private key, or you don't. Otherwise, it's just like SMTP: the underlying protocol could easily be under-lying, because that protocol does not enforce security -- that's what the certificates are for. That said, if you have a site, you owe it to your customers to get a certificate name that matches. All of them. Then again, given the 1:1 certificate per IP-port requirement, that expectation may be unreasonable on IPv4.

33.3% failure on my server by this measure (1)

dbIII (701233) | more than 3 years ago | (#32726486)

In my case I only have three domains connecting to one server, others have many more. Of course only one third of all random connections in my case will succeed. Obviously that one domain is where I expect any legitimate SSL requests to go.

MS Exchange and SSL (2, Interesting)

DigiShaman (671371) | more than 3 years ago | (#32725608)

In the Microsoft world, SSL Certs are primarily used for Sharepoint, Exchange Webmail, Outlook Anywhere, and Exchange ActiveSync for iPhone, Droid, and other PDAs. You can't configure them wrong or you'll know immediately that the implementation is broken. So how in the hell can we have 22 million invalid certs?

i.e. 22 million virtual sites (2, Insightful)

Culture20 (968837) | more than 3 years ago | (#32725628)

22 million virtual sites sharing IPs where only one site on an IP really needs the SSL, and the other sites weren't configured to only listen to the http port(s).

Duh (2, Interesting)

nickdwaters (1452675) | more than 3 years ago | (#32725662)

Most people don't care. How many commerce engines are running in the background handling transactions? As long as the point to point transaction is "secure", who cares if its linked to the domain. The vast majority of people running mom and pop shops, or even in the tech industry doing dev / testing, don't care about tying certs down to a domain because they use lots of domains / change often and its a pain and viewed as a waste of time to manage all of them.

Re:Duh (2, Insightful)

durdur (252098) | more than 3 years ago | (#32726128)

It is not secure if you can't verify the host you are connecting to. Having a valid certificate that matches the host helps ensure that you haven't connected to some rogue site that is masquerading as or acting as a proxy to the site you think you are connecting to. That is not as unlikely to happen as you might think.

But it not only end users who decide not to care about this. As other posters have noted, it costs money to be compliant. It also costs some time and trouble to generate and set up a proper certificate chain. And the perceived cost of not doing this is small - it still works, just click on through the warnings. But there's still a cost - maybe a big cost if an successful attack is launched against the site.

Non-browser apps that are SSL clients also frequently fail to verify host certificates, because their developers are too lazy to implement it and/or not security conscious enough to consider it important.

Ha! Ha! Fool me once! (1)

NicknamesAreStupid (1040118) | more than 3 years ago | (#32725682)

For some reason, I thought this common and recurring problem was mine. "How could so many sites have this mismatch?" Duh, silly me. Next thing I know, my bank will lose all my money, and my home will drop in value below my mortgage balance. Nah, never happens.

This doesn't sound very interesting or shocking (1)

Chuck Chunder (21021) | more than 3 years ago | (#32725690)

Presumably a lot of these are just domains hosted on some shared box at a cheapo web host that happens to have an SSL port open, probably for the administration control panel rather than for any of the domains it hosts.

My dog has a valid certificate (0)

Anonymous Coward | more than 3 years ago | (#32725720)

Oh yeah, she is a high class bitch.

Re:My dog has a valid certificate (0)

Anonymous Coward | more than 3 years ago | (#32725878)

My hair is a bird. Your certificate is invalid.

It's all too hard (2, Interesting)

countach (534280) | more than 3 years ago | (#32725744)

When it was my job to install SSL certificates, understanding it, buying the right certificate and installing it was freakishly difficult. Everyone from the certificate issuers to the server software providers needs to get together and simplify the whole process.

Re:It's all too hard (1)

jappleng (1805148) | more than 3 years ago | (#32725860)

I agree, I still can't figure out how to install the SSL certificate. For something that costs about $500/yr. they sure suck with their customer service or online tutorial. Thankfully my server came with SSL at "no cost".

Re:It's all too hard (1)

Vellmont (569020) | more than 3 years ago | (#32726184)


When it was my job to install SSL certificates, understanding it, buying the right certificate and installing it was freakishly difficult.

I've done it on several different servers for many years. "Freakishly difficult" is more than a little bit of an exaggeration. For something I do once a year, it might take me 10-20 minutes to figure out how to do it again, but beyond that it's not THAT difficult. It could be easier, but how easy does something you do once a year per domain really have to be?

Buying the "right" certificate is all just marketing baloney. If you want to piss away money you can buy the expensive "extended validation" cert that maybe 1 person out of 1000 will ever care about. Beyond that it doesn't really matter.

Park benches... (1)

myowntrueself (607117) | more than 3 years ago | (#32725830)

I remember reading a comment to the effect that:

"Using SSL to secure transactions between desktop browsers and web servers is like using armored cars to transport bags of money from one park bench to another."

Only 22 milion? (0)

Anonymous Coward | more than 3 years ago | (#32725916)

Surely they do. Over the past month I have generated about 10 million SSL certificates two times within my own PKI infrastructure just for the pure purpose of scalability and load testing and reproduction of production affecting issue. I do wonder who was the shmuk that generated the other two million.

Lots a Problems with This (1)

repetty (260322) | more than 3 years ago | (#32725928)

How about companies that use publicly registered SSL certificates for private LAN servers?

Too many wholesale assumptions here.

Bad Design? (1)

Sarusa (104047) | more than 3 years ago | (#32725938)

While I doubt the 3% for several reasons other people have mentioned, I have noticed just how freakishly evil it is for even otherwise competent admins I've dealt with to get SSL certs working properly. It seems like something that's so important yet so seemingly designed to thwart you at every turn is either a horribly bad and cobbled together design (it's certainly /fragile/) or specifically intended to increase Verisign's consulting and certificate generation revenues.

Only 3%? Not bad! (0)

Anonymous Coward | more than 3 years ago | (#32726018)

Did anyone else think they meant only 3% of sites didn't match? 3% of sites do match - wow.

Qualys = Security for Dummies (2, Insightful)

Gothmolly (148874) | more than 3 years ago | (#32726110)

We had a decent Infosec guy at our shop, then he left the group, and they bought a Qualys scanner. Now I get chimps telling me that I might be affected by an Apache 2.0 bug, and so I'm vulnerable. I ask what the bug does, and nobody can say, other than "The Qualys test failed". Great. If I send in enough box-tops, can I get my CISSP too?

Exactly (2, Informative)

Frosty-B-Bad (259317) | more than 3 years ago | (#32726252)

Funny, when Firefox went to the new style of annoyance (three step process) I made a post on the message boards to go back to the older style where it just prompted that it was invalid, click okay and you kept going. The devs/admins/users blasted back about how it was needed, how it helped, etc, and just as told them (a year + ago), finally research shows that most certs are invalid and out of date, but thats allllright because I quit using FF. It just scares me that the people that are smart enough to be involved with the programming and management of one of the most used web browsers have no insight to how the web is operating beneath them, don't they ever surf outside the mozilla domain? Weird.

Sounds like flawed assumptions to me (2, Insightful)

scdeimos (632778) | more than 3 years ago | (#32726286)

Many moons ago, when I worked for a web hosting company, they had Host Header servers for the low-cost customers.

A given server may have hosted up to 1,000 customer sites all on the one IP address by using the Host header introduced in HTTP/1.1 on tcp/80 (http), but they still had a single SSL certificate representing the server itself on tcp/443 (https). A reverse DNS lookup on the hosting IP returned the server's FQDN, which matched what was on the SSL cert's CN. Apparently this was something commonly done in the web hosting industry due to the ever-decreasing pool of IP addresses (this was in the days before TLS/SSL had mechanisms for clients to request a given certificate CN during the negotiation phase).

I wonder... did the discussed tests perform a reverse-DNS lookup on the web site's IP address before trying to connect to the https port? Was the result of that reverse DNS lookup used to compare against the SSL cert's CN, or did the test blindly assume that the CN must match the original site's FQDN?

The thing is ./ (1)

AnAdventurer (1548515) | more than 3 years ago | (#32726292)

I don't care if the SSL matches the domain. That's what my bank is for. If I am scammed (and my card was captured once and I found I was being charged $19.95 a month by a "Healthcare" company based in Greece, I am 100% sure was a scam) I call my bank and say "HEY, someone snagged my card and is using the number!"

So what I care about is the encryption side of SSL., I perceive that snooping is more likely then stolen card numbers as I am pretty careful about what online shops I use. But its all a crap shoot.

Worthless article written by total idiots... (2, Insightful)

Anonymous Coward | more than 3 years ago | (#32726372)

Think about their conclusions for a second. They are saying the SSL certs are worthless because the CN does not match the hostname. Why would millions of sites continue to pay ~$100 each year for a cert that will spout scary warnings in ALL browsers when their customers visit their web site? Surely this number of commercial organizations are not being that retarded so there must be an alternate explanation. Namely the author of the article and or Qualsys are total morons who are wasting our time.

Of those systems they reached how many happen to have multiple DNS records pointed at them and the domain they tried would never be used by any human person actually accessing resources of a site?

Of the systems they reached how many have a valid certificate chain? (IE were actually signed by a well known CA) vs certs that just have ssl certs installed by default with web servers or web based application servers?

How many times do you go to your bank or shop for something online or check your email and experience a cert CN/hostname mismatch error? I would be willing to bet that for most of us the answer is very close to 0.

self signed, public access (1)

gbrandt (113294) | more than 3 years ago | (#32726472)

I suspect that most of those are for 'private' use. I personally have a self signed certificate so that I can do secure webmail from anywhere. Webmail is at a public address where anyone can see it, so a check would show an invalid cert. But in reality, it doesn't matter at all.

The number are skewed and probably meaningless because I strongly suspect I am not the only one doing this.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...