Thousands of SSL Certs Issued To Unqualified Names 128
Trailrunner7 writes "The recent attack on Comodo and several of its associated registration authorities has spurred quite a bit of re-examination of the way that the Web's certificate authority infrastructure works--or doesn't. One interesting result of this work is that the folks at the Electronic Frontier Foundation have discovered that there are more than 37,000 legitimate certificates issued by CAs for unqualified names such as 'localhost,' or 'Exchange,' a practice that could simplify some forms of man-in-the-middle attacks. 'Although signing "localhost" is humorous, CAs create real risk when they sign other unqualified names. What if an attacker were able to receive a CA-signed certificate for names like "mail" or "webmail?"' Such an attacker would be able to perfectly forge the identity of your organization's webmail server in a "man-in-the-middle" attack!'"
No news here (Score:1)
How is this new? People have been using internal server names (fully qualified and not) for a long time.
In fact, Microsoft Exchange "best practices" state you should be using the unqualified server name as one of the SAN entries in the SSL cert.
Re:No news here (Score:5, Informative)
It is new because you would issue a cert for the internal host from your own internal CA. In this case a remote, third-party, seemingly trusted CA has issued a cert for an unqualified host. That's a massive difference and a huge cause for concern.
Re: (Score:1)
Re: (Score:2)
Sounds like the ideal reason to be using an internal CA to me.
Re: (Score:2)
To avoid "this is an un-trusted root CA", you should use a public cert.
Is it better to setup the cert properly to not give errors, or teach your users to ignore them?
Re: (Score:3)
I'd rather teach users to get IT to install our internal CA certs onto their devices before they'll connect so that all the other internal services signed by our CA will work correctly as well.
Of course, we could just pay some "trusted" chimps for a wildcard cert for our internal domain, but having our own certificates with direct control over them and the ability to issue whatever we need when we need it is somewhat preferable.
Re: (Score:3)
You know you can add your internal CA to the trust chain and take care of the problem without having to abuse the system, right?
Re:No news here (Score:4, Informative)
http://www.apple.com/support/iphone/enterprise/ [apple.com]
Re: (Score:2)
One easy way that we use (small company here) is that iTunes will sync trusted CA's from the paired computer to the phone so any office laptop has our CA on it and iTunes will sync it to the phone which then sees it..
As for removing it when they leave - the phone is ours.. we keep it and wipe them.
Re: (Score:3)
"set up the cert properly" means to tell the mobile device about your CA.
Re: (Score:3)
If you want nonstandard certificates, you should setup your own internal CA and add that CA as trusted on the devices where you need it. Devices where you cannot add a CA shouldn't be using SSL to access unqualified hostnames. In those cases get a certificate for the fully qualified hostname, and configure the device to use that.
Re: (Score:3)
It takes a few minutes on a linux netbook. I think any company can afford 15 minutes and a $250 netbook.
Re: (Score:2)
You should also add in the time it takes to install that cert on every device.
There are 2 basic attitudes I see here:
1. Who cares if the user gets errors, they should have installed the cert
2. Just set it up according to Microsoft's recommendations and not have users complain.
#1 will result in numerous calls to whatever helpdesk is available. In the extreme, you get the owner/ceo/exec/etc... barking at you because they don't understand the error message. Or, you use an internal CA and have to manually
Re:No news here (Score:5, Informative)
You should also add in the time it takes to install that cert on every device.
If it's a small company that doesn't have the money to set up their own CA, which was the initial basis of your argument, then they also won't have hundreds or thousands of devices to import the CA cert into. If they have a dozen employees, then it'll take all of 45 minutes to install the cert on an iPhone for all of them.
There are 2 basic attitudes I see here:
1. Who cares if the user gets errors, they should have installed the cert
2. Just set it up according to Microsoft's recommendations and not have users complain.
#1 will result in numerous calls to whatever helpdesk is available. In the extreme, you get the owner/ceo/exec/etc... barking at you because they don't understand the error message. Or, you use an internal CA and have to manually manage all devices. What do you tell the owner when they get a new phone on Sunday morning and ask you why they can't just set it up.
The user shouldn't have installed the cert. If the user can install certs, then you've got much bigger security issues than an error message in the browser. The IT person/department/support company should install the cert. You also don't have to manually manage all devices. I love these people that think they know enterprise IT, because they can plug in a printer and share it between their two home PCs.
Most devices allow some type of remote, group policy based management. If they don't, they really don't end up in businesses. Windows machines can have the cert added by group policy from the domain controller. Blackberry devices have a management platform that allows for similar group control. iPhones have it, too, from what I understand, although I don't support them myself, so I have to go on input from others.
And when the owner gets his new phone, and wants to set it up to check his email on Sunday morning? You tell him that unauthorized devices aren't allowed to connect, to protect his executive bonus from being rerouted to a cracker's swiss bank account. You can relax the security measures, if he puts in writing that he's ok with losing his bonus to crackers. Otherwise, you can set up the phone for him first thing Monday morning when he gets to work.
#2 results in no errors for the end user...it just plain works. The only ones who seem to have a problem are engineers/techs that don't seem to care what the end-user experience is.
You can go about this either way. It's your choice.
I prefer to setup systems so that users don't need to call me every time they get a new device, computer,etc. That is what the autodiscover service is for!
A good end user experience for wireless networks is for any user-provided device to just be able to connect to the network with a click or two, and immediately be able to access anything they need. Of course, this means that your wireless has to be completely unencrypted, with no firewalls protecting anything at all, no passwords required for access, or what have you. Because if there was even a slight impediment to the end user, it would be a bad user experience.
Is that seriously what you're recommending?
Security practices are there for a reason. Sometimes you get overbearing idiots who want a 78 character alphanumericspecial password with no repeated characters, no writing it down, and you have to change it every week, true. Overreaching "security by rulebook" is sometimes counterproductive.
But having "legitimate" CA providers giving out certs for "mailserver" and equally generic hostnames, is downright dangerous. You can do that kind of thing safely with your own CA, because after you've imported the CA cert into your devices, your "mailserver" cert will be allowed, but not some MITM cracker's "mailserver" cert, because it wasn't generated by your CA. Your CA is only recognized within your organization, on your own devices.
When Comodo, Verisign, or anybody else is generating "mailserver" certs, then absolutely anybody with a browser is at risk of their "mailserver" being impersonated by anybody else's "mailserver" cert, because the CA is publicly recognized.
Re: (Score:2)
And the easiest end user experience is inevitably the one with zero security.
So yes, that is what you're advocating. You just don't want to admit it, or maybe don't even realize it yourself.
Re: (Score:2)
But this mythical small company might not be able to afford such expensive products.
Note, that was sarcasm.
Re: (Score:2)
Yeah, I'm going to have to disagree with you on this one.
Software-wise, it's free or nearly so. You can do it low tech by managing your CA activities via the Linux/Unix command line or you can use more elaborate GUI packages that are available.
Very doable.
Now, I will concede that just about any upper-level manager in any IT organization that you might happen to ask would agree with you but they're just holding out for more funding -- that's just their natural knee-jerk reaction.
Re:No news here (Score:4, Interesting)
Yea, its uber tricky ... if your using an OS that wasn't actually designed for enterprise use.
I freaking hate defending MS, but in a domain/active directory setup, running your own internal CA is painless. The CA cert is automatically pushed to all machines in the domain so the domain can function properly anyway so every windows machine is covered by default. Cert expired? no biggy, republish, click click click, entire domain updates within 24 hours, small offices within minutes.
Users don't need to know anything about CAs or certs, the OS and servers do their job and take care of all that for you.
Unix machines aren't as nicely integrated into ActiveDirectory so you have to manage those some other way, but if your a company of any size at all, you've already got a way to manage your unix boxes don't you?
Running your own CA is only an issue if you don't know what you're doing, i.e. not an admin, just someone who plays one for their local business who doesn't know any better. If you have a clue, its not particularly difficult.
Of course, the fun flip side to that is ... I can and have issued a fully trusted cert sites outside our network in order to snoop on encrypted traffic via an SSL bouncer, and since the cert is signed by our internal CA, everyone validates it just fine.
Re: (Score:2)
I don't quite understand what difference it makes.
Re: (Score:1)
Because .local is a valid TLD that could be used in the future. Current MS advice is that your domain should be of the form corp.example.com where example.com is any domain you legitimately own.
Re:No news here (Score:5, Informative)
Re: (Score:3)
A widely trusted CA shouldn't issue certificates for unqualified hostnames. It is a bad practice. And if a document calls a bad practice for a best practice, I'll question the validity of said document.
However, I think the main target for criticism should be the SSL clients. When a client access a domain name that is not fully qualified, it should expand it to a ful
Re: (Score:2)
Wouldn't be the first time MS has a very 'interesting' interpretation of best practice. Remember how long it took for Exchange to stop using 'accept-then-bounce' inste
Re: (Score:2)
Wouldn't be the first time MS has a very 'interesting' interpretation of best practice. Remember how long it took for Exchange to stop using 'accept-then-bounce' instead of outright rejecting the SMTP session for an unknown recipient?
Remember though the reasoning for that - rejecting immediately allows for a reasonably high-speed dictionary attack to harvest the email addresses in the organisation. Remember also the timing of that decision - the 90's, not the late noughties. For example, consider the following approach:
Re: (Score:2)
Stop being an apologist.
There is no excuse for this behaviour.
Mart
Re: (Score:2)
This is a terrible reasoning. Yes, it does increase the resource usage for dictionary attacks a bit. However, it increases the resource usage for the server even more. In addition it causes innocent bystanders to be flooded with bouncing messages.
If you want to slow down somebody scanning for valid addresses, then just delay the responses to
Easy fix (Score:1)
Software should automatically reject certificates for unqualified names, even if properly signed.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Because you cannot advertise unqualified domains on the wider DNS system, its typically called the intranet zone, and IE in particular uses it to raise the trust level (for example IE may p
Re: (Score:2)
A browser can already tell the difference between qualified and unqualified - it has nothing to do with DNS itself, and everything to do with the presented domain. "myhost" is unqualified, and "myhost.example.com" is qualified - it doesn't matter if "example.com" exists in the wider DNS system, thats not even checked.
Sorry, but no.
Say you're on domain "foo.com" and connect to "myhost.example.com" and "myhost.example.company".
The former is a FQDN, but the latter is an unqualified address, which will (hopefully) take you to myhost.example.company.foo.com.
How do you propose the browser tell the difference between the two without asking a DNS server for SOA records?
Re: (Score:2)
The trouble is the lusers have gotten used to thinking that 'foo.com' is the proper way to type an address, when they want 'foo.com.'. The browser can try foo.com and then its going to try foo.com.{something from my domain search suffice list}..
Re: (Score:2)
The trouble is the lusers have gotten used to thinking that 'foo.com' is the proper way to type an address, when they want 'foo.com.'. The browser can try foo.com and then its going to try foo.com.{something from my domain search suffice list}..
And this neatly demonstrates how the "domain escalation" approach would work for certificates.
When the browser is provided with https://foo/uri [foo], it will use the configured DNS suffixes to find the server and then use the same DNS suffix to confirm that the connection should be trusted. So if you have mydomain.com. and mydomain.net. as your DNS suffixes, and foo resolves in mydomain.net., then the certificate must contain foo.mydomain.net. to be accepted.
Mind you I haven't programmed the sockets API so I don
Re: (Score:2)
That would break domain hosting.
The same machine that hosts company1.com also hosts company2.net and company3.org
Of course, the web servers should be smarted and present, if present, a certificate that matches the Host: line in the HTTP request, and not have a static certificate.
Anyhow, back to the original post, yes, non-fully-qualified certificates are both legal and have their use. Consider a network that isn't Internet, with its own DNS root servers, for example. If a customer wants a certificate for
Re: (Score:2)
The certificate is used before the Host: header is sent. There are some fixes in the works for this.
Charge the CA with complicity in any attacks (Score:5, Interesting)
These are not names the CA should be issuing. The only reason for issuing them is greed.
Make the CA aware that should any illegal activity be done using unqualified names that the CA will held legally responsible.
Watch the unqualified names disappear overnight.
Re: (Score:2)
Mod Parent Up.
Typically considerations for setting up an Exchange 2007 / 2010 CAS is to have a UCC cert that contains both the qualified and unqualified name of the CAS server (or CAS server array). This is to prevent Outlook from throwing a cert error when accessing the server internally.
While I can't speak to the security implications of such certificates, I can say that this is most certainly not something "controversial" that the SSL providers are doing, it's simply meeting a legitimate customer need.
Re: (Score:2)
It is possible for an internal DNS server to resolve your mail.example.com to your local 10.x.x.x inside and let your external DNS tell the outside world the external address. If you are a very small shop and don't want to set up an internal dns server you could even just modify the host file on the boxes that need to access the internal servers.
Re: (Score:2)
It's not actually an issue with 2010 any more as you should be specifying FQDNs for the RPCClientAccessServer values on your databases and Outlook will pull the necessary information out of AD when setting up new mail profiles.
Re: (Score:2)
You're doing it wrong. This is not a legitimate need, this is folks doing it wrong.
Re: (Score:2)
The problem is that the whole system was rigged to keep pointing back to "pay a CA for a cert".
In a system designed for security first, a server could easily have multiple identities, each supported by an independent cert (The web has finally grown that appendage in the form of SNI). The internal name of an exchange server would be backed by an internal Cert signed by the company's internal CA (with it's key installed on all employee machines) and the external name would be backed by a public cert signed by
Re: (Score:2)
Of course, any cert would be usable to sign another cert so that example.com could use it's example.com cert (signed by a generally recognized CA) to sign their own cert for api2.example.com. Validation would be a matter of following the signatures until you get to a known and trusted cert. But we couldn''t allow that since it would conflict with "pay a CA for a cert" on the api2 site.
Uh, what? The reason that doesn't work is nothing to do with "pay a CA for a cert". The reason that doesn't work is that it would completely break the trust model. What you're suggesting would allow a criminal to obtain a certificate for dodgy-site.com (legitimately, since you believe CAs should not be allowed to verify identity and all that stuff because it's "just profiteering"), and use that to sign a cert for bankofamerica.com. Voila, instant MitM.
Essentially, your idea is foolish and ill conceived.
Re: (Score:2)
The default level of trust would be the least trusted in the chain. Presumably, dodgy-site.com would be trusted only to sign subdomains of dodgy-site.com. That is, you trust that they really are dodgy-site.com because a CA you trust says so. That doesn't mean you believe they are conscientious enough to verify others identity for you. If you know and trust dodgy-site.com, feel free to make their cert a trusted introducer in your browser.
I never said CAs shouldn't be allowed to verify identity anywhere. The
Re: (Score:3)
Making a corporation legally responsible for its action is like striking at water with a sword. They'll pay the fine, and the executives will still swim in the money.
No! (Score:3)
A certification is a statement of opinion. (And furthermore, it is a statement by a complete stranger who has no relationship with you and owes you jack shit.) The sooner we learn this, the sooner we will start to work on real solutions to the problems (i.e. switch to OpenPGP). If you charge CAs with complicity, you are just legitimizing the flawed idea behind our current CA infrast
Re: (Score:2)
The funny part about your post is that you think PGP doesn't suffer from the exact same set of problems, AND a whole bunch of others that make it absolutely useless to normal people who don't want to be bothered with the fact that it was designed and meant to be used by a bunch of geeks trading keys.
You can't get through life if you trust no one, you'll die of starvation in your home. I have no urge to personally meet all the people I communicate with regularly in order to exchange keys, nor do I have any
Re: (Score:2)
It doesn't suffer from the problem, because it's based on accepting the idea that you're never fully sure. That is how real life works. Some people are confident that their government never makes mistakes and issues ID to the wrong people, combined with a personal confidence that they are very good at spotting fake IDs. And some people aren't sure about both of those things at all, so they want to see t
Re: (Score:2)
A certification is a statement of opinion. (And furthermore, it is a statement by a complete stranger who has no relationship with you and owes you jack shit.)
The same can be said about passports and other government id papers. Does the border guard personally know the guy who issued you your passport? No? But yet he trusts it.
Re: (Score:2)
(And furthermore, it is a statement by a complete stranger who has no relationship with you and owes you jack shit.)
I know I'm going to get modded to hell for suggesting this, but why aren't governments in the business of issuing certs? Governments already issue DBAs and IDs, so why wouldn't it be ideal for them to issue the digital equivalent?
Re: (Score:2)
Most browser have a set of criteria for certificate inclusion. One of these is typically an independent audit of their practices. I'd suggest that Mozilla should immediately drop all of these CAs, and require a $100,000 recertification if they wish to be included again. Their customers will then complain that, in between now and the time that they completed the recertification, all of their customers got scary warning messages. Gives a strong incentive for CAs not to do this kind of thing again.
Re: (Score:2)
Why not? If you set up your own CA you can issue any name you want as well, I can issue hotmail.com or fbi.gov. SSL certificates are NOT meant to identify a website, they are merely there to secure the link between a server and a client. When people (and browser makers) understand that, we will be quite a bit further.
Re: (Score:2)
The problem is that the browsers trust CAs which are unscrupulous.
I have a solution!!!! (Score:5, Funny)
Therefore, I propose the following: All browsers shall be required to stop trusting those inexpensive standard SSL certs, as well as certs issued by budget CAs. 'Extended Validation' certs will now be baseline, with prices remaining unchanged, and two new levels of verification will be added:
'Extended Validation: Pinky Swear!'(indicated by a green background with two interlocking pinky fingers) will have the same standards as 'EV'; but with the additional promise that we had the work experience kid, or a script, whichever is cheaper, check that the certificate request wasn't made from a hotmail account.
'Double-Secret Extended Validation'(icon TBA, pending negotiations with film rightsholders) is so secure that we can't even tell you the process by which we verify applications; but it is super secure.
This should solve all CA related trust issues.
Re: (Score:3)
Re: (Score:2)
These kinds of certs would be more than adequate for individuals, small orgs and whatnot who want the security of a cert without paying a tax to a CA just so they can bless the cert with virtually worthless "trust".
I don't understand why the likes of Firefox / OpenSSL / GnuPG and other vested interests in the open source movement aren't
Re: (Score:2)
I don't understand why the likes of Firefox / OpenSSL / GnuPG and other vested interests in the open source movement aren't pushing for a free model for certification which cuts the CAs out of the loop, at least for some kinds of certs.
Indeed. Especially since there is a free CA around: CaCERT [cacert.org].
Yes, they failed an audit. But the only reason why they failed it was that they were doing it honestly. Many other CAs which are currently accepted in Firefox would fail the same kind of audit, but they are smart enough not to submit to one.
Re: (Score:2)
The whole system also has a chilling effect on private communication with sites not using a cert who potentially could and should. I believe th
Re: (Score:2)
In CaCERT's case if I want a cert I have to present my government papers to somebody in their web of trust. And I have to do it every 2 years. For what purpose?
Actually, you need only show your identity documents to someone in their web of trust once. The identity validation is good "for life", and is associated with your cacert account. The certificates issued by cacert are valid for a maximum of two years, after which time one can get fresh certs (indeed, one can get certs revoked and new ones issued at any time).
Re: (Score:2)
Re: (Score:2)
Why?
I keep reading similar comments over and over again but I really want the use case is! I agree it does not make any sense for browsers to treat self signed certs as riskier than plain HTTP, but why use HTTPs without authentication.
Put another way, why worry who can see what your saying when you don't know who you are saying it to anyway?
I totally understand a self signed cert for say connecting to a private network you control and have the certificates for. A company installing a their private CA cert
Re:I have a solution!!!! (Score:4, Informative)
Where you don't care about a determined attacker but want to stop a casual eavesdropper.
For example a blog where you want to require users to login. Stolen passwords are a pain but not a major issue but being able to stop people just sniffing them off unencrypted wifi connections makes sense.
Or want to stop ISPs seeing/hijacking pages to insert ads. Although ISPs could do a MITM attack on self signed certs, it's likely that before very long someone will notice an ISP doing it to one cert at which point people will very quickly see that it's happening to all of them.
Many (most?) SMTP servers will negotiate TLS with self signed (or non "official" CA signed certs) if it's available. It would be interesting to know how many email servers are setup to refuse to send if the cert cannot be verified. I'm sure there are some servers out there that do this (and they're probably only allowing manually installed CAs as well) but I expect they're few and far between.
Even between my home mail server that receives my mail and the backup mailserver I have if my home server is unavailable I forward using TLS (and the CA is installed) but I've not even considered bothering to block it if the certs don't match. If MI5 or the police decide they do want to intercept this mail then I probably wouldn't notice as the only visible symptom would be in the mailserver logs where it would no longer say the cert verified OK but someone at an ISP in the link is not going to accidentally start copying my mail traffic like google did with WIFI.
Tim.
Re: (Score:2)
The reasoning is that the vast majority of the time, no one is doing a man-in-the-middle attack and furthermore that doing a man-in-the-middle attack on any significant proportion of the connections on the internet is assumed to be above the capabilities of any known attacker, so it means that you are probably talking to the owner of the DNS entry and normal passive sniffing attacks (ex. Firesheep) won't work. Also, the attacker may not be able to tell which connections are verified and which ones aren't (e
Re: (Score:2)
All browsers shall be required to stop trusting those inexpensive standard SSL certs, as well as certs issued by budget CAs. 'Extended Validation' certs will now be baseline, with prices remaining unchanged, and two new levels of verification will be added:
'Extended Validation: Pinky Swear!'
'Double-Secret Extended Validation'
This should solve all CA related trust issues.
I read this an laughed, but then when I thought about it, you should not even suggest this kind of idea.
Making it more expensive to be secure is not a step in the right direction.
Re: (Score:2)
and two new levels of verification will be added: .... 'Extended Validation: Pinky Swear!' ... 'Double-Secret Extended Validation'
Well played sir.
Re: (Score:2)
Re: (Score:2)
Or how about we just give up with the idea of for profit third party authentication altogether and use either a handful of open authentication sites or just fall back on a distributed web of trust. I find the whole idea of founding our public key encryption systems on trusting a private, for-profit corporation to be laughable to begin with.
And the Mozillia/Firefox Debacle over self-signed certs would be funny right now if it wasn't so offensive.
Re: (Score:2)
just fall back on a distributed web of trust
Won't scale up, as it fails to take into account the fact that the world is full of idiots and assholes. Assholes will try to poison the trust web ("for great profit!") and idiots will act in ways that let the assholes do it without any way to get back at them.
The problem with the system of CAs is that nobody seems willing to pull the plug on crap ones. If CAs knew that they'd get kicked out of the magic money farm for screwing up, they'd take the right level of care. (Especially if they'd then have to fend
Re: (Score:2)
I don't see the problem. The existing process simply needs to require you to send something (by snailmail, email, or fax) on Company Letterhead.
Since "using fake letterhead to spoof a request to a CA" has recently been patented as a business method, the patent would stop any bad guys from requesting fake certs, and all your certs are now secure, again.
Wheres the data coming from? (Score:3)
Re:Wheres the data coming from? (Score:5, Informative)
From the main page [eff.org]...
Re: (Score:2)
I'm talking about the origins of that data, where did it originally come from, how can they compile datasets of SSL certificates (which have no centralised point other than the CAs themselves - so are the CAs giving out information on cert signings?)
Re: (Score:2)
For their big-map-o'-CAs, it looks like the information you would need would be within available browsers, which by necessity come with a list of CAs that they trust, possibly with a bit of legwork to see if there are subordinate CAs involved...
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
you crawl https on mail.nonlocalhost.com, and discover it claims to be domain "mail", and present a cert for domain "main".
That host doesn't listen on port 443 (https), and on port 993 (imaps), it uses a self-signed certificate for *.mail.dreamhost.com
Still very goofy, but not quite as bad as a certificate for mail signed by a "legitimate" CA.
Re: (Score:2)
they probably are doing something like the below script :)
please ignore the invalid IPs, localhosts, private ips, multicast, etc, this is just a quick script... a perl version would probably be faster and more intelligent
for a in {0..255} ; do ;do :443 2>/dev/null | sed -n 's%0 s:.*/CN=\([^/]*\).*%\1%gp' > https.log
for b in {0..255}
for c in {0..255} ; do
for d in {0..255} ; do
echo | openssl s_client -connect $a.$b.$c.$d
Re: (Score:2)
What a coincidence (Score:2)
I was just working on a PC with a virus that routes all traffic through some sort of SSL MITM mechanism.
Surely that depends on what you name your mail ser (Score:2)
Our mailserver has a REAL fqdn.... mail.XXXXX.com. Its only ever refered to by this.... so how would having mail as a cert help? :/
We knew this (Score:2)
I'm sorry, but haven't most of us, in the back of our minds, known all along that the whole SSL thing is just a money scam?!
Even if the commercial CA's get there act together, there are still plenty of CA's that my browsers trust by default but are in fact highly suspect. SSL can provide real security, but not through public CA's that are blindly included in your browser/OS.
Re: (Score:2)
yes!
time to read this - definitions of trust
http://mcwg.org/mcg-mirror/trustdef.htm [mcwg.org]
"webmail" where I work (Score:2)
It would be immediately obvious when someone performed a MitM attack using a valid certificate for "webmail". Why? Because the real certificate is signed by a ghetto CA that isn't trusted by any of the "major" vendors, and both the certificate and some of the intermediates have long since expired.
I'll be worried if I can access that site without a bunch of ugly warnings popping up.
Re: (Score:2)
Rofl. So true, so true.
Re: (Score:2)
I don't understand. When submitting for an SSL cert I don't recall ever providing an IP address. Praytell how does an SSL cert know that I am on the proper IP Address?
Re: (Score:2)
Domains are your identity on the web. IPs are your location. Certs verify identity of computer you're talking with, they don't need to contain IPs.
Re: (Score:2)
You're stupid and stupid should be banned.
Wildcard Certs are very handy. They aren't "generic" as you say, they are a specific kind of cert. We use them all the time, for nothing other than to get logins out of plain text on servers that don't really need to be "secure", so that people sitting in Starbucks can be safer from wifi session hacking when using those servers.
Wildcard Certs serve their purposes, and just because you don't know what those are, doesn't mean they are "stupid". It means you are the st
Re: (Score:2)
I run a Really Small website that I'm trying to start up (and I'm not going to plug it, I'm weird like that). I don't really want to pay for an SSL cert since none of the data on the site is useful to hackers or criminals. The one exception is: passwords. The fact that people reuse passwords all over the place gives every website operator a great responsibility to protect passwords. Salts, modern hashes in the database, complexity requirements, all of it is moot if a MITM can just look at the raw login form
Re: (Score:2)
PHP generates the public key, sends it with the javascript in the form, all the form data is encrypted by the browser itself before sending it to the host.
And how do you protect against a man-in-the-middle changing the public key while it is being sent from PHP to the browser? Or against same middleman just adding some more javascript to the page which copies the sensitive form fields into new fields which will be transmitted in the clear (like happened in Tunisia with facebook...)?
Re: (Score:2)
Excellent question and good point. I guess I'm not really protecting against a true man-in-the-middle attack who has dedicated time and resources. It'll stop eavesdroppers, though. For now, and as long as my website isn't a money-maker and self-certified sites cause browsers to throw up frightening warnings, that will have to be good enough. I'll still suggest people don't use the same password on two sites.
Re: (Score:2)
Startssl.com is recognized by all major browsers, checks your identity by a mail and phone callback, and issues as many "simple" certificates as you need. "Simple" meaning no wildcard, and no subject-alt-name. These are valid for one year
If you do need more advanced stuff (wildcard, subject-alt-name), you can have StartSSL do a more "thorough" id check. For this, upload a scan of two g
Re: (Score:2)
Sorry to be snarky. :-/
I come off like the ass I am sometimes.
Re: (Score:2)
Those aren't quite as generic as you think.
That covers a.example.com. It doesn't cover b.a.example.com
Re: (Score:2)
Because entering 'mail' in my client is far less annoying than mail.hq.internal.mydomain.com, and it has the added benefit that if I make an image that talks to mail rather than mail.hq.internal.mydomain.com it can be deployed at any other site and still function correctly. So an image made on hq.internal.mydomain.com also works on nyc.internal.mydomain.com and lax.internal.mydomain.com without any additional work.
Re: (Score:2)
Re: (Score:2)
"Huge amounts"? GoDaddy offers widely-trusted certs [godaddy.com] (their roots are in all major browsers, and also chain back to the old ValiCert root so it works with ancient browsers) for about $13/year. Hardly "huge amounts".
StartSSL [startssl.com] has their root in all major browsers, and they issue certs for free. (Naturally, they also offer Class 2 and EV certs for money, but their basic domain-validated certs are free.) While the PKI model has its flaws, StartSSL seems to be doing The Right Thing within the confines of the model
Re: (Score:2)
To understand if there is even a problem you first need to check the key usage/EKUs of these certs to see in what context the certificates are allowed to be used.
Do browsers check these key usage/EKUs? If not, these certificates could still be used for nefarious purposes, even if such usage is against some paper document somewhere...
And if yes, I'd think EFF would have raised less of a fuss...
Re: (Score:2)
The global CA infustructure is used for a lot more than just securing public web sites.
To understand if there is even a problem you first need to check the key usage/EKUs of these certs to see in what context the certificates are allowed to be used.
The global CA "infustructure" (sic), used in any scenario, fails to ensure the trust is certified, absolutely.
It's down-right broken, should be abandoned IMMEDIATELY!!!.
Wait! Before you mod me troll or skip past this thinking I'm a nut-job, ask yourself this: Does a "valid" cert PROVE that the domain named in the cert actually requested the cert be made? Well, does it?
NO. It does not!
A "valid" cert only proves that a "trusted" authority has signed the certificate. A "valid" cert in no way ensur
Re: (Score:2)
Excuse the self reply, but a colleague pointed out an interesting point: "Securing Everything means no caching"
Interesting, yes, but totally incorrect. Data that is to be cached can be signed instead of obfuscated via encryption, thus yielding security AND caching capabilities. Web browsers currently warn that a page contains both secure (encrypted) and unsecure (non encrypted) items. If a third option of, "signed but not encrypted", were available, the page could would no-longer contain both secure