New Extended SSL Certs Make Online Debut

An anonymous reader writes "The first of the new 'extended validation' SSL certificates went live this week, signaling the latest effort by the browser makers and major Web sites to further verify the identity of SSL applicants and help consumers spot fraudulent Web sites, the Washington Post's Security Fix blog notes. The technology is pretty simple: Visit a login page for a site that uses one of these EV certs and the browser bar turns green; likewise, the browser's anti-phishing filters can turn the URL field red when the user is at a known phishing site. There is still quite a bit of debate over whether this whole scheme isn't just a new money-making racket for the SSL providers, and whether small mom-and-pop shops will be able to afford the pricey new certs."

Comments

It isn't whether they can afford them.

[khasim]

It isn't whether mom-and-pop shops can afford the new certificates.

It's whether they'll be allowed to purchase them.

That's because sole proprietorships, general partnerships and individuals won't be eligible for the new, stricter security certificates that Microsoft requires to display the color.

Re:It isn't whether they can afford them.

[rumith]

As far as I understand, the main trouble for mom'n'pop shops will be the green colored bar [which they will have a hard time obtaining, as opposed to larger companies]. What is the problem of marking connections established with old certificates green too, at least on non-Microsoft browsers? Another point: is the green bar alone enough of customer value so people go buying in 'those green internet shops'? Would things like comfortable product search, navigation and price suddently stop mattering?

Re:It isn't whether they can afford them.

[mastershake_phd]

That's because sole proprietorships, general partnerships and individuals won't be eligible for the new, stricter security certificates that Microsoft requires to display the color.

Thats because we all know there is no such thing as a shady corporation with enough money for expensive certifications.

Re:It isn't whether they can afford them.

[wfberg]

sole proprietorships, general partnerships and individuals won't be eligible for the new, stricter security certificates that Microsoft requires to display the color

Ironically, it's much easier to establish an individual's identity (many databases that you can look in and merge, require multiple forms of ID, etc.) than the fact whether an individual is actually a proper agent of some huge megacorporation.

Re:It isn't whether they can afford them.

[noz]

It's whether they'll be allowed to purchase them.

Yet another poorly moderated comment. The parent is not "Informative": neither does it quote detail nor simply related to another. It is an original thought developing insight into the consequences of the system under discussion.

It seems most slashdot moderators have insight and information confused. Compare the above to this comment which is informative, not insightful.

Re:It isn't whether they can afford them.

[ShaggyBOFH]

Here's an interesting phishing site (according to Microsoft)... Department of Navy's Recruitment Site of Civilian Jobs.

By the way, the worst job search page ever created.

Re:It isn't whether they can afford them.

[b0s0z0ku]

That's because sole proprietorships, general partnerships and individuals won't be eligible for the new, stricter security certificates that Microsoft requires to display the color.

Most mom-and-pop shops probably go through an order clearinghouse like PayPal anyway, so once you go to the order page there'll be a green bar.

-b.

Re:It isn't whether they can afford them.

[zecg]

That's what I was thinking. If I had points, I'd mod you up.

Re:It isn't whether they can afford them.

[beadfulthings]

Well, it is and it isn't. The cost of filing as a limited liability corporation (LLC) isn't all that bad. Our lawyer (who has handled wills and other family matters) will do it for somewhere between $300 and $500. He actually dissuaded me from setting this up a couple of years ago because, as he points out, there aren't any real advantages for a small retail business. The true cost at this point lies in the price of the EV certificate, which is a real shocker. Verisign, for example wants $1299 for a one-year period. That's a lot of money, and there's really no way to establish how much credence online buyers are going to put into this new validation. It's also a "special introductory offer" with the regular price being $1499.

What's irritating to me is that I've been a sole proprietorship for almost six years now. I can furnish bank and credit references and tax records to that effect. Seems as though there ought to be a way to verify through those records.

I already ante up extra $$$ for a cert from a well recognized authority. But $1299?

Re:It isn't whether they can afford them.

[eneville]

It isn't whether mom-and-pop shops can afford the new certificates.

It's whether they'll be allowed to purchase them.

That's because sole proprietorships, general partnerships and individuals won't be eligible for the new, stricter security certificates that Microsoft requires to display the color.

its just more reason for people to jump browsers and use something that's not a pain in the ass.

Re:It isn't whether they can afford them.

[Chalex]

Not only that, but free Certificate Authorities (like CAcert.org) are not allowed to issue these EV certs. Only the large commercial CAs like Verisign can issue them. reference: http://blog.cacert.org/2006/11/194.html

Re:It isn't whether they can afford them.

[init100]

Not only that, but free Certificate Authorities (like CAcert.org) are not allowed to issue these EV certs. Only the large commercial CAs like Verisign can issue them.

Not allowed? By whom? I understand if Verisign very much would want this, but do they have that power? Are all browser vendors in on this "conspiracy"?

Re:It isn't whether they can afford them.

[Zeinfeld]

Mom and Pop Shops will have no difficulty getting the Green bar if they use Paypal or the like as their shopping basket.

The woman quoted on the WSJ site does not have a certificate today, she uses a Paypal shopping basket. So quite why she thinks that she would want an EV cert is not clear.

Mom and Pop shops that are incorporated can get a cert like anyone else. The issue is not size, it is what is being authenticated. The EV stage 1 rules specify minimum standards for authenticating incorporation credentials. This is not possible if the applicant is not a corporation.

The CABForum is currently working on rules to allow certificates to be issued to sole traders etc. These should be ready in a few months.

Re:It isn't whether they can afford them.

[Zeinfeld]

What's irritating to me is that I've been a sole proprietorship for almost six years now. I can furnish bank and credit references and tax records to that effect. Seems as though there ought to be a way to verify through those records.

Length of time that a company has been in business is a pretty good indication of legitimacy. The question is how to codify the rules in a form that works internationally.

There are certainly sole traders who hold organizational validation certificates today but the vast majority are for corporations, government agencies etc. I would suspect that most of the sole trader certs are for code signing rather than SSL. At this point there is no enhanced user experience for EV code signing and resolution of the sole trader issue is generally considered to be a necessary first step.

It is important to remember here that the object of the exercise is to be able to tell the consumer when the purchase they make if backed by accountability.

The CAs would very much like to sell EV certs to anyone who is willing to buy one. One of the intentional features of the go green user interface is that it shows the issuer name. If the issuer messes up the relying party can hold the issuer accountable.

Re:It isn't whether they can afford them.

[pallmall1]

I wish my browser had a red bar for Fanboy alert.

Re:It isn't whether they can afford them.

[Tony Hoyle]

Well, it is and it isn't. The cost of filing as a limited liability corporation (LLC) isn't all that bad. Our lawyer (who has handled wills and other family matters) will do it for somewhere between $300 and $500.

It's a *hell* of a lot cheaper than that.

Your lawyer was price gouging.

Re:It isn't whether they can afford them.

[zymurgy_cat]

Ironically, it's much easier to establish an individual's identity (many databases that you can look in and merge, require multiple forms of ID, etc.) than the fact whether an individual is actually a proper agent of some huge megacorporation.

Very true, and my experience is that most places don't even make an effort.

Last year, I decided to get a signed certificate for a site that my company uses for internal purposes. When I provided the information, the CA called me and pointed out that I needed to prove who I was by submitting a phone bill with the phone number I provided. Mind you, they called that phone number to ask me to provide information proving that it was my phone number. I obtained a record from a website that I faxed to them. Yes, I could have edited the page before printing.

The kicker is that my phone number is in a different state than the company's. (I work out of my home.) No one ever flagged this or attempted to contact the home office to verify that I was an employee or authorized agent.

Re:It isn't whether they can afford them.

[(Score.5, Interestin]

Well, it is and it isn't. The cost of filing as a limited liability corporation (LLC) isn't all that bad. Our lawyer (who has handled wills and other family matters) will do it for somewhere between $300 and $500.

It's a *hell* of a lot cheaper than that. Your lawyer was price gouging.

The reason why it's cheaper for shell corporations is that they're exactly that, pre-generated cookie-cutter shells. Getting an existing, operating business switched over requires considerable legal work, and is therefore rather more expensive.

Re:It isn't whether they can afford them.

[sowth]

I would add incompetent companies to that. Plenty of companies will lose info, send the wrong package, send to the wrong address, have really stupid policies, etc. Every company will have problems from time to time, but some more than others. You won't have any idea unless you check them out, and no cert is going to tell you what issues a given company has.

Dealing with screw-ups can be as bad or worse than a scam....

in addition, even if the cert does weed out all pure scammers, I doubt it will take out companies with really bad/stupid/dishonest policies. I used to work for a place where one of their buyers would call a partial shipment a "gift" if they received the other partial shipment the day before. Then they would call and insist upon being credited for the product they "hadn't received." Do you really think a CA will deny or even understand to revoke a cert for such a company who makes such California claims? How do they now the person complaining isn't the real scammer? After all, there is no proof that the company actually asked for the shipment, and sending somethng without a request counts it as a gift (in my jurisdicion), so how do they know? I doubt they would even take the time and resources to investigate to such detail anyway...

That is why review sites are important. The reviews may not be 100% accurate, but reading a bunch of posts should give you an idea what you can expect...

Interesting problem

[zappepcs]

Do we end up paying for new methods to make the Internet safe (supposedly) or should we spend the money trying to educate people to recognize when they are being sent to a phishing site?

I predict (brave of me, I know) that no matter what efforts are made to protect Internet users, there will still be phishing on the Internet.

I think we're better off with the training.

Re:Interesting problem

[Anonymous Coward]

No, we keep reporting all the green bar sites as phishing sites rendering the whole thing pointless and making the whole thing a silly expense for all the companies stupid enough to buy an EV cert.

Re:Interesting problem

[nine-times]

With training, you still have the problem that some people are utterly and incurably stupid and careless. Security (in general) should be a multi-pronged initiative. You should educate people how to be secure and how to spot potential security issues, but you should also, where feasible, make it difficult for people to do insecure things.

Re:Interesting problem

[b0s0z0ku]

With training, you still have the problem that some people are utterly and incurably stupid and careless.

The best teacher is experience. Once the stupid and careless people get burned once or twice, I'm sure that they'll learn to be more careful in the future. Their lesson just might be a bit more expensive than the lesson given to quicker learners. BTW, in my experience, if you just look at the URL bar before entering private information, this takes care of 999 out of 1000 spam/phishing scams. If the URL bar is correct and it's still a scam, someone internal to the company is probably running the scam, so they would use a good certificate anyway. The lack of proper grammar and suspicious structure (you know it when you see it) takes care of most of the others.

-b.

Re:Interesting problem

[zecg]

I think we're better off with the training.

Certainly, just as soon as our fifty million trainers finish eradicating AIDS through instructing people to practice safe sex.

The small guy is getting shafted

[truthsearch]

Entrust plans to sell its EV certs at $499 apiece per year (and that's its "intro price")... Verisign, the world's largest and probably most recognizable SSL provider, has set its price for EV certs starting at a hefty $1,300 per year.

The smallest of legit web sites will not pay this, especially when they're just starting up. Add to that the requirements (what type of corporate entity the site belongs to) and you'll have few small takers. This is definitely going to hurt small sites as all of the medium and large sites will eventually sign up. Users will eventually expect the green bar on every site where they might do business. So I see this as merely a money making scheme. If they really wanted to improve security they wouldn't rely on the type of corporation or charge such high fees.

Re:The small guy is getting shafted

[John Hasler]

> Users will eventually expect the green bar on every site where they might do
> business. So I see this as merely a money making scheme. If they really wanted
> to improve security they wouldn't rely on the type of corporation or charge
> such high fees.

It isn't just a money-making scheme. It also serves to drive out small businesses and set the bar higher for startups.

Re:The small guy is getting shafted

[anagama]

Users will eventually expect the green bar on every site where they might do business.

I'm not necessarily disagreeing with you, but it is also possible that so many legit businesses will fail to get these, that people will expect them only for the largest corporations. In other words, people will get so used to seeing a yellow bar or whatever color they choose, that they'll start ignoring it.

Another option is to use a payment processor who's big enough to afford one of these and make it clear to customers that the financial part of the transaction will be carried on through the payment processor's site. If there aren't enough payment processing businesses, this will spark them.

Or maybe you are right and this will kill internet commerce. I certainly hope not as I'm on the verge of opening a small online myself.

Re:The small guy is getting shafted

[ceejayoz]

It's not $500/year for extra security, it's $500/year for the level of validity SSL used to offer.

Re:The small guy is getting shafted

[truthsearch]

Why would Verisign or Entrust want to drive out small businesses or set the bar higher for startups? It's in their best interest to have as many customers as possible. I think they're just trying to sqeeze more money out of people, and if that hurts small business, well they don't care.

Re:The small guy is getting shafted

[b0s0z0ku]

My small retail store pays more than this every month just in power and phone bills. I have -zero- sympathy for a "business" that can't pay $500/year for extra security.

There are plenty of home-based businesses that have essentially zero capital when starting up. Remember that $500 is a lump-sum payment and can equal a month's rent for some people in some places. You could use a payment processor or even only accept money directly face-to-face, but will people start thinking that all companies without a green cert are untrustworthy, even if they don't take money and personal details online? This amounts to a protection racket not much different from the goons that came to brick and mortar stores and said "we need some money to protect you from thugs breaking into your store at night and torching it."

-b.

Re:The small guy is getting shafted

[zecg]

This is definitely going to hurt small sites as all of the medium and large sites will eventually sign up.

I predict differently: it's eventually not going to matter at all. Since only a small percentage of online destination will make the bar turn green, it'll never be viewed as a necessity - merely as a shiny luxury item that certifies a site is big and expensive. But (IMO) it will not decrease the volume of business for small sites and it will never become standard expectation. Not at those prices for certification.

Doesn't matter.

[Z00L00K]

There will certainly be somebody that can take advantage of this too. The only thing that SSL actually tells you is that the traffic you have is encrypted. The only thing that this really does is to provide an incentment for the bad guys to crack the solution since it will mean that there may be more money to gain at the sites that relies on those SSL certificates.

Don't trust anybody - not even yourself!

Re:Doesn't matter.

[TheSunborn]

No, ssl also tell you who you are communicating with.

Re:Doesn't matter.

[nine-times]

The only thing that SSL actually tells you is that the traffic you have is encrypted.

Maybe I'm not understanding what you're saying, but part of the idea of SSL certificates is also to verify that the site you're connecting to is actually the site it's claiming to be. You can use SSL to encrypt the traffic without this feature, and maybe there are ways around SSL anyway, but if you don't want 3rd-party certification of your identity, you don't need to pay for SSL certs anyway.

Re:Doesn't matter.

[Beryllium Sphere(tm)]

All SSL really knows is what public key it's communicating with.

It will download a data structure in which the public key and some character strings are authenticated with yet another party's private key.

The rest is hope and trust that the signer does due diligence and hasn't been compromised.

If the "certificate" does prove who you're communicating with, SSL doesn't tell you that until you click on the padlock and look up certificate properties. Until then, all it's told you is that the domain name matches. If West African Phish and Game buys a certificate for "paypal-reverify.com", SSL will not warn you about them. This isn't hypothetical.

Netcraft confirms it :-) More than 450 Phishing Attacks Used SSL in 2005

Nice gig for the Certificate Authorities

[Anonymous Coward]

The purpose of a Certificate Authority is to verify the identity of the person who requested the certificate.

Since they've done such a bad job of this so far (it was quite strict at first), they've now turned around and offered a more expensive certificate with the promise that this time they'll _really_ do their job.

I've no doubt they'll get away with it when all the big names buy the more expensive certificates and see an opportunity to squeeze out the smaller competition, and/or otherwise help to raise the barrier to entry for their market. Watch this get a lot of media attention and advertising.

Re:Nice gig for the Certificate Authorities

[canuck57]

Since they've done such a bad job of this so far (it was quite strict at first), they've now turned around and offered a more expensive certificate with the promise that this time they'll _really_ do their job.

The only certs I trust are the ones I personally sign. So when I am on a PC without the signing CA, it pops up and I can view it. If it isn't mine or one I expect I know a Bluecoat or some other SSL in the middle device is at work. The only way I know to protect against it is to view the cert each and every time you are about use it. Which self signing does this nicely.

Re:Nice gig for the Certificate Authorities

[sjwest]

Well there Sales operation is good and no im not trying to troll

Looking into certs, requested a free pdf, send all your details, click ok and wham bang thank you mam expect a pdf to download - nothing there. Think about something else and a week later Vogan from verisign rings

can i help

I politelly tell him that his request form was screwed up and no we would not be using you and could he please go jump under a train.

I learnt to make my own ca's - Vogan and Versign pretty useless but good at salesmanship.

Re:Nice gig for the Certificate Authorities

[doj8]

As said by others, these new certificates are simply the old certificates with the verification work done. The first SSL cert I purchased entailed several weeks of verification, a copy of business paperwork, calls from the certifcate authority to the office, personal identification, listed phone number, and such. It took two tries to get everything right. The last SSL cert took 15 minutes and only required an email account. This is inexcusable.

The certificate authorities are supposed to be involved in the business of trust. They fell down on the job. I do not know who opened the floodgates by first issuing these "drive-by" certificates. I know everyone followed suit because they would have lost business and consumers simply don't know better than to demand more.

The browser bar color change might help a little, but since most people don't even know that they are visiting a secured page now, I doubt it'll help few more people than those already in the know.

(I do technical support for a living, and have been explaining these issues since the secure web first emerged. I fully expect to receive a number of calls complaining about the changing color and asking for it to be fixed.)

Re:Nice gig for the Certificate Authorities

[Tony Hoyle]

The last cert I got wanted the company number.. or to be exact they wanted *a* company number. They didn't verify anything else (in fact the registration address is our accountants and is unrelated to the rest of the company).

They sent the cert the same day.

Verification of 'limited company' status is bullshit anyway. I can buy an off the shelf limited company for £30 over the web, and apply for a certificate tomororrow if I want.

Re:Nice gig for the Certificate Authorities

[LordLucless]

Of course, the reason there was an incentive for these drive-by certs is that the bundling of encryption/authentication is moronic. The reason businesses want certs isn't so their customers know it's them - for the most part, the customers already trust the website. They want them for encryption, even though technically encryption can be done without one. The reason customers look for the little padlock isn't to verify that this site really is amazon.com - they already think it is. They look for the little padlock to check their credit card details are being encrypted, and to reassure themselves that the transaction is safe (even though the little padlock doesn't tell them anything about how their details are stored on the receivers end, and that's probably a larger point of failure than a man-in-the-middle attack).

Re:Nice gig for the Certificate Authorities

[doj8]

I can incorporate a business in my state for US$115 with online forms. I don't know how quickly they issue a company number now, but before the Internet it took about a week. Other states & countries may be cheaper, easier and faster. So, it is easy to create a quick corporation. So I agree verification of corporate status is not useful. A D-U-N-S number (Dun & Bradstreet) takes no more than 30 days. It doesn't verify much information either from my last experience. Since phone services are fragmented (between VoIP and multiple providers), the presence or lack of a phone directory listing isn't definitive. For example, all my company's lines are VoIP based and we have no phone directory listing as we have no wired lines at all, however, we've been in business 25 years. A listed phone number could simply ring to a service, not indicating the validity of the business. Of course, I have not RTFA, so I don't know precisely what verification is going to be used. Simply using the incorporation is meaningless, as you said.

Re:Nice gig for the Certificate Authorities

[doj8]

> even though the little padlock doesn't tell them anything about how their details are
> stored on the receivers end, and that's probably a larger point of failure than a
> man-in-the-middle attack

You are correct. Nor does it indicate whether they have a keylogger installed on their system either. So, you have two effectively untrusted ends and a secured channel between them, yielding, at best, a modest increase in security.

Encryption should almost be the default nowadays. That is completely separate from verification of the destination, however, and perhaps should never have been conflated with it. If certificates clearly indicated their level of verification (and, presumably, their security) ("drive-by" quickies being, say, amber through thoroughly verified certs backed by insurance being green) then perhaps the public would grasp that the padlock is not a simple on or off, but a range of trust.

Again, this doesn't ensure anything about the quality of security on the vendor's end at all, though perhaps it should. If these extended verification certificates can be dynamically changed if/when the vendor has a security breach, then that would be of value. So XYZ.com had a green certificate until they lost 150,000 credit cards from a dumpster dive and they now have a sickly yellow certificate until they pass a security audit and rectify the breach and consequences. That would be too much to hope for and, to be honest, would be damned expensive to implement. That is the level that banks, credit card companies, other financial institutions, governmental and medical records, and the like ought to employ, IMO. Requiring such for a mom & pop business selling jams and jellies would simply be overkill.

But, the new certificates don't appear to possess the range of nuances needed to express the range of trusts that are needed for the different sorts of activities.

Trust is not a binary function. It is a spectrum.

Verifying fingerprints is even more secure

[jannic]

Instead of relying on the trustworthiness of third parties issuing the certificates, one could easily verify the key fingerprints directly.

Unfortunately, browsers make this unnecessarily difficult, and few sites (even online banking sites) publish their fingerprints offline. Wouldn't it be easy for a bank to print the fingerprints in a letter sent to the customer, possibly together with his credit card etc.? If then there were an easy way to show this fingerprint in a web browser, without clicking through several layers of complicated 'key details' pages, people could actually be sure to connect to the correct site.

Additionally, I miss a feature to lock a site to a given key. Say, I'm regularly connecting to the same site, like slashdot. I don't care if the slashdot site is actually related to some company with the same name, or whatever CAs try to tell me with their certificates. All I want to know is if the site I'm sending my password to is really the one I have been visiting since several years, or a fake one trying to steal my password. So all I need is a big warning whenever the site key changes.

Both are not too difficult to implement, I guess, but users need a little more training than just telling them 'a green browser bar means secure'.

Re:Verifying fingerprints is even more secure

[Anonymous Coward]

Your plan won't work, because the site cert didn't change. You're just at www.slashdut.com instead of www.slashdot.com. Their SSL cert says they are www.slashdut.com. So what's the browser going to do?

Re:Verifying fingerprints is even more secure

[jannic]

It does show that I'm at slashdut.com, and as I don't want to be there, I'll leave that site and head for slashdot.org, instead.

Of course, I could miss that little difference in the domain names. But that's not solved by high-security-certificates, either, as slashdut.com may actually be registered by a corrupt company with that name and may have bought a matching high-security-certificate.

Together with my 'lock current key to current site'-idea, this could be solved by making the browser bar green only if I'm currently surfing a website using a key which I have approved myself in the past. This would be a much better indicator of a valid site than a certificate by some random company.

Re:Verifying fingerprints is even more secure

[John Hasler]

Great ideas, but they don't serve a "business purpose".

Re:Verifying fingerprints is even more secure

[Anonymous Coward]

The you are still trusting the US Mail, and that the letter you received was actually from the bank (and not a fake)

This is about just as secure than a corporate 3rd party who wants all browsers to continue using them as a trusted source, in terms of the cert for your bank.

To truly have trusted transfer of the signature (or beter yet the private key, since we don't want someone to find a birthday case of the MD5 or SHA1 or whatever other hash was used) You and the other party need to meet and very securely transfer the key.

Realistically the 3rd party is fine, as they will do as secure as posible to accept the users data and sign the cert. and you trust said 3rd party to have the right level of security. Mind you since you need to trust this 3rd party you still might want to kill your browsers default certs, and conduct the very secure transfer in person with the CAs you trust. (and if those CAs don't have your banks cert, maybe still get that from your bank directly)

(and I do agree looking at cert information should be easier)

Re:Verifying fingerprints is even more secure

[butlerdi]

This does already exist. No need for third party providers. Take a look at http://www.httpy.com/ with an implementation shown at http://www.waterken.com/dev/Browser/ Great idea and simple. Just not much profit incentive for the big boys .

Re:Verifying fingerprints is even more secure

[beebware]

Well, there's a sort of way of doing this in Firefox. Have it remember your username for the site - if it doesn't pre-fill the username for you when you go back to the site, get a bit more worried and be really especially careful before manually entering your login details...

Six dumbest ideas...

[jginspace]

"should we spend the money trying to educate people to recognize when they are being sent to a phishing site?"

The Six Dumbest Ideas in Computer Security - See #5 - 'Educating Users'.

That's really trustworthy!

[wfberg]

I don't know specifically which bit in the certificate makes the address bar green, but the idea of these certificates is that the CA took extra super care to make sure they weren't issued to some bum, but to the people the certificate says it was issued to.

The example in the article immediately points out a failure of this idea. Go to entrust.com and your address bar turns green. And who is the CA that has verified that this site is really operated by entrust? "Entrust or an independent local registration authority has verified that Entrust Inc is an existing business and owns or operates the domain name www.entrust.com".. Yeah. So, this is basically a self-signed certificate, but it turns up green, because you're supposed to trust entrust, because you're supposed to trust entrust, because you're supposed to trust internet explorer.

Meanwhile, their 'extra validation' CPS states that they offer no warranties or guarantees, nor any detail about what they DO do to make extra super sure they don't issue certificates to some random Joe.

Re:That's really trustworthy!

[Jerf]

For better or for worse, shipping the user a browser that defaults to trusting nobody isn't going to happen anytime soon.

If you did ship a normal end-user a browser that trusted nobody, it would be equivalent to shipping one that trusted everybody, as they'd learn to "just click 'yes'", so while it's theoretically superior, it isn't practically. You can try this; you're free to remove all that automated trust.

Although you could make a case that no automated trust is better than inaccurate automated trust.

I guess the take-away lesson here is that when you add "uneducated and uneducatable users" into the mix, security gets really, really, really, really hard. (Note that I'm not claiming all users are uneducatable, but the number is non-zero and I'd personally guess around 15%, which is significant.) Unfortunately, "something" must be done, and by golly, "something" will be done.

Re:That's really trustworthy!

[Anonymous Coward]

It doesn't seem to work anyway. If go to entrust.com using IE7 the address bar stays white. Has anyone seen it turn green?

Re:That's really trustworthy!

[legirons]

"Meanwhile, their 'extra validation' CPS states that they offer no warranties or guarantees, nor any detail about what they DO do to make extra super sure they don't issue certificates to some random Joe."

You're assuming that they're in the business of being secure and trustworthy, as they claim. It makes more sense if you think about their business as taking a toll on e-commerce websites.

"Pay us money, or Internet Explorer will tell your customers not to trust you"

Would it matter to them if a load of people got incorrecly certified? So long as business need to pay them before their site is "trusted" by the default browser, I can't imagine them being too bothered about actual security (other than for appearance).

Re:That's really trustworthy!

[Beryllium Sphere(tm)]

>...because you're supposed to trust internet explorer.

And continue trusting after it's been installed for a while. Bruce Schneier once asked the obvious question of how hard it was to add a new trusted root. It's trivial, and there's a "web accelerator" on the market that installs itself as a new trusted CA so that it can proxy SSL traffic.

Re:That's really trustworthy!

[Metasquares]

I think you can probably tell the users to ignore the IE alert and a good deal of them will do just that without question.

Re:That's really trustworthy!

[Kalriath]

I get a message from Internet Explorer saying "To protect your security, Internet Explorer has blocked this website from displaying content with security certificate errors" Wow. Makes me want to get SSL certificates from these guys!

Re:That's really trustworthy!

[Kalriath]

Found out why too:

For Windows XP users, EV functionality in Internet Explorer requires that the Phishing Filter be Turned On for automatic website checking. If you do not see the green URL address bar when trying the demo, and are running Internet Explorer 7, this setting might be turned off. Please check the Phishing Filter settings in the Advanced Tab by clicking Tools > Internet Options > Advanced.
Who honestly leaves that thing turned on at all times?

Re:That's really trustworthy!

[marcello_dl]

Yep, one of the problems is that ie lies to you.

IIRC, and in the italian localization, ie6 said about my site that the user CHOSE NOT TO TRUST that CA (I setup my own CA, it's for internal use). Except that user never did that (especially at first connection)
ie7 says "blah blah... connect to site anyway (discouraged)"

At least firefox is honest, says "I can't verify this CA, do you want to trust it always, for this session, never?"

As i said i have no public users so i can instruct people to trust the CA. Public sites should setup a link to explain the situation on the login page, there were dedicated sites explaining the dangers of eu patents so something centralized would be nice.

Re:That's really trustworthy!

[Anonymous Coward]

How much do you want to bet that I could write a page with a green bar across the top that read super duper secure site (maybe include a official looking graphic) and have thousands of clueless users trust it?

$1200 per year

[Anonymous Coward]

We all know $$$ doesn't buy security. However I do think that Microsoft is open to a class action law-suite by treating none enhanced certificate holders differently.

Great

[finkployd]

So, the CA oligopoly is now going to be charging extra for doing the assurance checking they should have been doing all along but now admit they were not. And once they decide they need more money I am sure they will claim that they have been screwing up their assurance checking on these new ones as well but for a little bit extra, they will do SUPER DUPER identity validation. Then we can REALLY trust the certs.

Why are we paying and trusting them again?

Finkployd

Gripes with HTTPS

[RAMMS EIN]

I have one major gripe with HTTPS:

If you don't pay the Powers That Be, you can still make your site more secure, but it will appear to be less secure.

The way HTTPS normally works is that you create a key to be associated with your domain name. This key is then signed by some certificate authority (supposedly after verifying you are you). If the certificate authority is one of those trusted by your visitors' browsers, the browser will go ahead and use your site, as well as display some indication that it is secure. The security includes both encryption (confidentiality) and authentication (you're really communicating with foobar.com - VeriSign says so).

However, you have to pay the certificate authority to sign your key. If you don't, you can still sign the key, but it won't be trusted by browsers. So far so good. The problem is that browsers will scream bloody murder, because they can't verify that you are you, making at look like you're attempting some kind of scam, while, actually, you're offering your visitors encryption. It's not as secure as encryption and authentication, but it's still better than plain HTTP - a protocol which browsers will accept without a hitch.

As a minor issue, the SSL key is sent during the connection set up, before the client can send a Host: header. This means that each host wishing to employ HTTPS has to have its own IP address - otherwise, the server doesn't know which key to use. There's actually a way around this: HTTP 1.1 specifies how to upgrade a connection to HTTPS, which can be done after the Host: header has been sent. Unfortunately, a lot of software appears not to support this feature.

Re:Gripes with HTTPS

[Anonymous Coward]

At the company I work for, we use such a cert, except that we have our root cert that our software installs during the installation procedure.

Yes I know, smart client + HTTPS is strange. Live with it.

Re:Gripes with HTTPS

[Sloppy]

However, you have to pay the certificate authority to sign your key. If you don't, you can still sign the key, but it won't be trusted by browsers. So far so good. The problem is that browsers will scream bloody murder, because they can't verify that you are you, making at look like you're attempting some kind of scam, while, actually, you're offering your visitors encryption.

I think what you have identified is a bad UI, not really a HTTPS problem. A browser shouldn't create popups or other warnings when using HTTPS without trusted authentication, or at least no more so then it does with HTTP (without SSL). Just don't show (for example) the padlock icon, or show it modified in some way. The browser should only show a popup or do other alarming things, when it has reason to believe the user is doing something unsafe. Maybe it sees the user submitting a form with a password field, or something that looks like a credit card number, and then notices that the info is being sent to someone who hasn't been authenticated. That's something to worry about, not the fact that a page of unverified origin is being displayed. A page can be displayed with passive information (e.g. padlock icon) about what the browser thinks of the origin.

Re:Gripes with HTTPS

[RAMMS EIN]

You're right that the problem is mostly with the presentation. However, HTTPS may also get part of the blame for not specifying an "no authentication (encryption only)" mode.

Re:Gripes with HTTPS

[modeless]

Encryption without authentication is and always has been a stupid idea. What's to stop anyone from self-signing their own certificate claiming to be Amazon.com? Nothing, that's what.

In order for an unauthenticated connection to actually be secure, you have to trust *every* *single* router your packets cross, because *any* of them can trivially break your encryption. Do you trust your ISP? Your ISP's ISP? Every other ISP between you and Amazon? Do you trust the coffee shop wireless access point? The free hotel Internet? With SSL, you don't have to. You could plug your Ethernet cord directly into a router owned by your worst enemy, and still feel completely secure in your HTTPS connection to Amazon. If browsers didn't warn about self-signed certificates, that security would be gone. The certificate authorities, obnoxious as they can be, are necessary to provide that security.

Re:Gripes with HTTPS

[_Knots]

Incidentally, there is an extension to TLS to embed the host name in the initial handshake, so that one need not use the Upgrade: extension of HTTP. I find this solution simpler, if also rarely implemented, but YMMV.

Re:Gripes with HTTPS

[RAMMS EIN]

``Encryption without authentication is and always has been a stupid idea.''

I disagree. It does prevent people from eavesdropping on your communication, which is valuable in itself. Sometimes, it's even enough: for example, for anonymous services, or for setting up a secure channel for authentication.

It's also worth pointing out that the authentication that SSL (and HTTPS) uses by no means guarantees that the other party is who they say they are. Yes, they have a key which was signed by a party which your software vendor trusts...but mistakes can be made an are made.

Personally, I don't trust VeriSign. A key with their (and only their) signature on it is worth the same to me as a self-signed key to me. For many transactions, that is enough trust for me. I'll log into my University's website to access the "students only" documents there, even though my browser pops up a warning about the certificate. However, I would be loathe to send data that I didn't want people other than the intended recipient over this or a similar connection.

Re:Gripes with HTTPS

[init100]

As a minor issue, the SSL key is sent during the connection set up, before the client can send a Host: header. This means that each host wishing to employ HTTPS has to have its own IP address - otherwise, the server doesn't know which key to use.

If you create a certificate with the x509_v3 extension subjectAltName set to a number of hostnames all those hosts can use the same certificate. I use this setup at work on an internal server that provides several name-based virtual hosts. The setup is further described here (called CN+subjectAltName). I don't know if this method is the one you referred to below:

There's actually a way around this: HTTP 1.1 specifies how to upgrade a connection to HTTPS, which can be done after the Host: header has been sent. Unfortunately, a lot of software appears not to support this feature.

Re:Gripes with HTTPS

[Anonymous Coward]

Correct; the Server Name Indicator feature is supported in Windows Vista's HTTPS stack. The "Upgrade" header idea is subject to a significant number of usability problems.

Re:Gripes with HTTPS

[rs79]

Fuckit.

Self sign your own certs.

If google and paypal can't get it right why should anybody else care?

all people should care about is it's encrypted. Do you REALLY believe CA's check who you are?

A previous posting regarding cert keys hit the nail on the head.

Re:Gripes with HTTPS

[Chandon Seldon]

You're right. It would make more sense to have no "accept this certificate popup at all" and to create a new "encrypted but not authenticated" icon to replace the lock.

Re:Gripes with HTTPS

[dkf]

It's also worth pointing out that the authentication that SSL (and HTTPS) uses by no means guarantees that the other party is who they say they are. Yes, they have a key which was signed by a party which your software vendor trusts...but mistakes can be made an are made.

You're obviously ignorant of many important aspects of how a practical PKI works. Two of the key things that a CA does are to publish a list of certificates that have been withdrawn before their scheduled expiry, and to add a URL to each certificate they issue that describes how software should verify that the certificate is not in the list (it's part of the data in the certificate that can't be changed without invalidating the certificate completely, though I don't remember its name or OID.)

Personally, I don't trust VeriSign.

So remove their certificates from your browser's list of trust roots. (For high-integrity work, we use SSL systems that are founded on PKIs with none of the big CAs trusted; sensible paranoia is a Good Thing sometimes.)

Re:Gripes with HTTPS

[dkf]

It would make more sense to have no "accept this certificate popup at all" and to create a new "encrypted but not authenticated" icon to replace the lock.

So now you can rest safe in the knowledge that you are either communicating directly with your bank or directly with some scummy phisher? That's such a useful thing to know! (It was said earlier, but it bears repeating: SSL encryption without authentication is useless, and this is because attackers are not always just passive eavesdroppers.)

Re:Gripes with HTTPS

[Chandon Seldon]

SSL encryption without authentication is useless

False. It prevents passive eavesdropping attacks.

The question here is very simple: How should the browser treat a self-signed certificate or a certificate signed by an unknown CA? There are four choices: 1.) Pop up a scary warning 2.) Treat it like a PKI-authenticated page 3.) Treat it like any normal HTTP page. 4.) Give it its own "encrypted/not authenticated" icon.

Option 2 is obviously wrong. The page can't be authenticated cryptographically, so we can't know "for sure" that it's authentic.

Option 3 is better than Option 1: A self signed certificate is slightly *more* secure than an unencrypted connection - it shouldn't be treated as less secure.

Option 4 is the best: It doesn't look the same as a PKI-verified page, but the user can see that a random snoop won't get their webmail password. If the address in the title bar is right, it's probably authentic anyway - DNS spoofing is pretty rare, and if the attacker is doing that you have bigger problems than them reading your webmail.

No impact whatsoever

[Anonymous Coward]

Just my 2 cents, I believe this "green bar in IE7" even if/when other browsers support it, won't matter. If I want to buy something I will buy it, with confidence.

That depends upon how you mean that.

[khasim]

Maybe I'm not understanding what you're saying, but part of the idea of SSL certificates is also to verify that the site you're connecting to is actually the site it's claiming to be.

That depends upon how you mean that.

If I get a certificate issued to server "apple" at "berry.com" with address 123.456.789.012, then that is all that you know from that certificate. The server's resolved name and address match the server name and address for which that certificate was issued.

But that is all you know. That means that that certificate cannot be moved to a different server. Even one owned by that same company.

But it tells you nothing about whether the site is who "it's claiming to be".

Example:
A phishing site can claim to be from Bank of America and have a legitimate certificate issued to server1.BoA-security.com. But it would not be a Bank of America site.

This new plan attempts to deal with that issue by making "green" certificates available ... but only to people who can somehow demonstrate that they're working for an established corporation. This is based upon the belief that corporations would be less likely to be used to setup a phishing site.

Now, whether that belief is accurate or not does not really matter. It just moves the goals AND causes concern amongst the mom-and-pop shops out there.

Debate? What debate?

[chill]

I thought it was obvious this was nothing more than a money-making scam. You know, like those "Privacy Certificates", where anyone with a privacy policy gets a cert. Even those whose policy says "we'll sell your info to anyone whose check clears"...

Good UI idea, bad (but improved) cert idea

[Sloppy]

The user interface aspect of this is a good idea. One of the bad things about x.509 up to now is that it's all-or-nothing; the other side's identity is either completely trusted or not trusted at all. Real life isn't like that, as pgp took into account a decade and a half ago. Acknowledging that there is a degree to which the other side has been authenticated, and then showing this in the browser, is a step in the right direction. I enthusiastically approve of this change to browser UIs.

On the non-UI front, things are a little less encouraging, but it's still a slight improvement (but with a dark side). It is a fact of reality that an identity certifier has limited resources and no matter what they do, they can be fooled. Letting the certifier put something into the cert to indicate how hard they tried to authenticate, is a good thing. When I sign someone's pgp key, it's good that I can indicate degree of trust; casual trust if all I did was look at someone's government-issued photo id, and strong trust if I actually know the person I'm signing (i.e. a fake ID wouldn't be enough to fool me). I am pleased that the x.509 system now has some sort of way to do this.

It's still unfortunate that they left the biggest weakness in the system, though. An identity is still only certified by one certifier. That's really dumb. Verisign can be fooled, Thawte can be fooled, I can be fooled, but fooling all 3 of us at the same time is a bigger feat, so that would be a great way to improve the amount by which an identity can be believed. That's something that pgp also figured out a decade and a half ago, but x.509 hasn't caught up.

But that leads to the dark side. I think there is a reason the system doesn't support multiple signers: it makes it easier for new CAs to enter the certifying "market", and also could lead users to think about how much they trust the big brand name certifiers. Suppose I claim to meet Amazon's keymaster and I sign their cert. The issue that 99.99% of users would face, upon seeing my signature on Amazon's key, is that they don't have the foggiest idea of who the hell I am or why they should trust me, so they would go into their software and make sure their trust level for me is zero (or really really close to zero). Actually that would be the default. But then it strikes the user: "Wait a minute, how much do I trust Verisign? I don't know any more about them, than I know about Sloppy." So the user then goes into their software and also sets Verisign to a low value. The user should only really trust people they have reason to trust. They probably wouldn't really delete Verisign from their list, but they'd set the trust level to very low. Probably not zero, as there's some "sheep factor" faith level in a big brand name. But the whole issue of thinking about who you trust and to which degree, would be a major threat to the brand name CAs.

I understand why Microsoft is willing to play along with the big CAs. I don't understand why the Mozilla, Konqueror, Safari, etc teams do. Supporting a multiple-certifier system (e.g. OpenPGP) would improve those browers with no apparent downside.

Entrust's SSL certificate, and its problems

[Animats]

OK, here's Entrust's SSL certificate. Let's see what we've got.

Domain: www.entrust.com

Server identity:
CN = www.entrust.com
serialNumber = DOC:19961216
OU = it
O = Entrust Inc
jurisdictionOfIncorporationStateOrProvinceName = MD
jurisdictionOfIncorporationCountryName = US
L = Ottawa
ST = Ontario
C = CA
Issuer identity:
CN = Entrust Certification Authority - L1A
OU = (c) 2006 Entrust, Inc.
OU = www.entrust.net/CPS is incorporated by reference
OU = CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND LIABILITY
OU = AND ADDITIONAL TERMS GOVERNING USE AND RELIANCE
O = Entrust, Inc.
C = US Certificate has 10 extensions.

• Extension #0: keyUsage = Digital Signature, Key Encipherment
• Extension #1: privateKeyUsagePeriod = Not Before: Jan 12 13:57:28 2007 GMT, Not After: Jan 12 14:17:41 2009 GMT
• Extension #2: extendedKeyUsage = TLS Web Server Authentication, TLS Web Client Authentication
• Extension #3: authorityInfoAccess = OCSP - URI:http://ocsp.entrust.net
• Extension #4: crlDistributionPoints = URI:http://crl.entrust.net/level1a.crl
• Extension #5: certificatePolicies = Policy: 2.16.840.1.114028.10.1.2 CPS: http://www.entrust.net/cps User Notice: Explicit Text: The Entrust SSL Web Server Certification Practice Statement (CPS) available at www.entrust.net/cps is hereby inc orporated into your use or reliance on this Certificate. This CPS contains limitations on warranties and liabilities. Copyright (c) 2002 Entrust Limited
• Extension #6: authorityKeyIdentifier = keyid:7E:B7:FC:4C:26:E6:B0:7A:FB:54:E2:3C:45:73:C6 :43:90:5E:28:04
• Extension #7: subjectKeyIdentifier = 10:E0:70:1B:D7:78:17:32:B4:BA:EB:00:6A:E2:25:C3:67 :FC:77:1D
• Extension #8: basicConstraints = CA:FALSE
• Extension #9: UNDEF = None (this is a bug in the cert. viewer)

The CA Browser Forum has published a standard for these certificate. So that's what we go by.

How do you tell this is an Extended Validation certificate? That's not in the CA Browser Forum's standard. It's dependent on the certificate issuer.

It's documented, on Entrust's web site "Each EV SSL Certificate issued by the Entrust EV SSL CA to a Subscriber contains an Object Identifier (OID) defined by the Entrust EV SSL CA in the certificate's certificatePolicies extension ... which by pre-agreement with Application Software Vendors, marks the certificate as being an EV SSL Certificate.

The following OID has been registered by the Entrust EV SSL CA for inclusion in EV SSL Certificates: 2.16.840.1.114028.10.1.2"

That OID number appears in the middle of a comment in the certificatePolicies extension. So, for each issuer, you have to look for something different.

The certificate checker has to be really careful. To verify that a certificate is an Extended Validation certificate, it's not enough to find that OID. You have to make sure that the certificate was issued by the issuer entitled to use that OID. Otherwise, it's easy to forge these certificates.

But if you're too thorough in the checking, the certificate bounces. The whole point of an Extended Validation certificate is to validate the company's identity. So we have the new fields "serialNumber", "jurisdictionOfIncorporationStateOrProvinceName", and "jurisdictionOfIncorporationCo

Re:Entrust's SSL certificate, and its problems

[ufohoaxer2]

"DOC:19961216" refers to the Date of Incorporation, which is 1996/12/16. It does not refer to the Maryland Tax Dept. ID #, which is "D04566428". Ottawa, Ontario is Entrust's Canadian headquarters. They probably do more work out of Canada then Texas, or maybe that's where most of their staff is located. I don't consider that questionable information. Could this have been done better? Probably.

Re:Entrust's SSL certificate, and its problems

[Animats]

No, the spec says, on page 9:

Registration Number:
Certificate Field: Subject:serialNumber (OID 2.5.4.5)
Required/Optional: Required
Contents: This field MUST contain the unique Registration Number assigned to the Subject by the Incorporating Agency in its Jurisdiction of Incorporation (for Private Organization Subjects only).

So when you go to validate the certificate against incorporation records, it bounces.

The whole point of Extended Validation certificates was that the organization was supposed to be identified unambiguously. Earlier versions of the spec required a full physical address of the business, but the CA forum backed off, and now companies can get by with just giving city and state, which may not be unique.

Re:Entrust's SSL certificate, and its problems

[Anonymous Coward]

You are totally correct. This could have been done better. In fact, as an ISV in the cert space, we have found it quite interesting that during the enforcement of these certificates many have the problems that you describe. For our product, which scans networks and maps the SSL infrastructure to customer defined policy this is problematic as these HA certs often are incorrectly set up. I fully agree that if this was done a bit smoother it would make the adoption that much easier - and ultimately the enforcement and related benefits would be more wide spread. http://www.certalertsoftware.com/

Re:Entrust's SSL certificate, and its problems

[Animats]

Since there's no public OID list for these certificates, I've added one to the Wikipedia entry for Extended Validation Certificates. Entrust, Verisign, and Comodo are filled in; if you can find the documented values for other vendors, please add them. Thanks.

MOD PARENT UP

[RAMMS EIN]

Good post; your analysis is spot on. If I had mod points, I'd mod you up. Alas, I've already posted in this thread.

There are many problems - some are legacy problems

[fyngyrz]

As far as I understand, the main trouble for mom'n'pop shops will be the green colored bar

It is far worse than that:

• This encourages people to "trust" Internet Explorer, which has not earned that trust in any meaningful sense
• This encourages people to "trust" Verisign and others, which have also not earned that trust in any meaningful sense
• This discourages customers from checking out an online shop themselves, which is just plain really, really bad
• This certificate is an additional expense not just in obvious costs, but in hoop jumping
• If a legitimate business is unable to obtain the cert, it will be unfairly damaged by the incorrect presumption of unreliability
• Certificates never provide anything more valuable than data security, the "identification" is illusory and worse with these, since they create an "underclass" of nominally "untrusted" sites that have no performance reason to be so classed, which is the very definition of an inaccurate take on who is trustworthy
• The idea that "trust" in one corporation can be settled merely by the endorsement of another is logically and realistically false
• Browsers, by buying into this corporate scam, have been complicit in hurting the Internet's ability to do business, not in helping it; this is because historically, identification of "who is trusted" has been poorly done by underdoing (in other words, give us a check, we'll give you a cert... just a scam, no ID involved) now we have a scam where it will be overdone, so that perfectly legitimate businesses will be left out in the cold. Again, the idea that a corporation can be trusted to do your due diligence on checking out someone you want to do business with is wrong from its very roots.

In the end, the benefit of SSL is that of encrypted traffic. The data goes from the client to the server, and nowhere else. That's what a certificate actually ensures. Nothing else. Not one blessed thing. The people who built this scam were either miserably uninformed and/or confused, or underhanded types who recognized the money to scooped up from people who could not afford to have a browser inaccurately claim that their business "might be a scam."

This is just one more case where superficial thinking about something is being used as an excuse to generate a large and healthy cash cow over and above the current certificate scam. Nothing can legitimately substitute for you checking for complaints, longevity, experience with the product(s) you are interested in, that sort of thing. Which in turn means that by definition, the foisting off on the consumer that the "browser bar turning green" means "shopping or interaction is OK" is outright illegitimate.

And will any of that stop this from happening? Not a chance. Because it isn't only the consumers that are failing to do due diligence here; it is the browser writers as well, and as per usual, we start with Microsoft who does not have the consumer's best interests at heart.

The attempt is being made here to do something that is impossible. Wy? Because an operation that was trustworthy yesterday can become untrustworthy tomorrow. Likewise, an operation that was controlled by scammers can replace those people. It is a matter of people and goals that no one can see through the veil of the Internet. This is aside from the creation of a "ghetto" of untrusted merchants who cannot get certified, or cannot afford to get certified.

I saw a comment elsewhere here by some moron who was pontificating about how "if some business cannot afford $500 for this cert, I would not trust them, etc. ad nauseam." The fact is, some businesses are striving on the edge and that money is important to them. Seeing as how it does nothing for them but keep them from being creamed by this new scam - meaning, it doesn't add value to what they do, just brings them back to a status quo

not first

[Wire3117]

Globalsign does this too already : http://www.globalsign.com/digital_certificate/exte nded_validation_ssl/index.cfm

SSL Certs are ridiculous.

[shaitand]

SSL Certs should go hand in hand with domain registration and every domain registration should include a wildcard SSL Cert for that domain. A cert isn't a valid way to prove that John Smith or company x controls the site, it is a valid way to assure that the content you are viewing is coming from bla.com. There is no reason that every domain on the web shouldn't have the ability to give visiters that assurance. It uses what, about a penny worth of electricty to generate a cert? Wildcard certs don't cost anything more to generate then individual certs. This would drastically increase the security of the web and allow independently operated non-commercial domains the ability to secure content.

Right now SSL Certs aren't being used to make the web more secure. Certs are being used to gouge online commerce sites so that a few companies can exist selling them.

Re:SSL Certs are ridiculous.

[Workaphobia]

Question: Assuming that certs and domain registration were tied together, what damage could DNS spoofing do to the integrity of this system? It would seem to be immune to that problem, but I don't know enough about this to be sure.

Presumed guilty until innocence is bought

[Anonymous Coward]

This is a thinly veiled protection racket. You're a sole proprietorship, general partnership or individual? You will be labeled as a possible phishing site, and lose potential customers. You are a small (or large) business? Pay up the $1300.00 per year, or you will be labeled a possible criminal and lose business too.

These certificates offer the business nothing of value. Pure racketeering.

This does little to actively protect the consumer, and once this gets hacked (my guess is sooner than later) it will do nothing to protect consumers. This only works in favor of large corporations by decreasing competition.

It has been claimed that the issue with small businesses & EV certs is moot, because Google checkout is getting more popular, paypal and ebay will surely get EV certs, and within a few years from now many online merchants will be providing paypal and Google checkout options.

Some small business prefer not to use third party 'shopping cart' services. This increases their overhead, and once again funnels money from the little guy into the pockets of corporations. Many small business owners are loathe to relinquish any control over their business. Also, some people find writing and maintaining their own (or FOSS) shopping cart to be just plain fun! Not to mention educational.

So, the solution for small business is to either PAY Entrust, or PAY Google et al? Not a solution, afaic. It's a scam.

I can't believe this doesn't violate anti-trust laws or racketeering laws. It's hostile to small businesses and completely excludes sole proprietorships, general partnerships and individuals, as they aren't even eligible for the green bar 'status.'

This causes far larger problems than it solves. This only marginally protects the stupid (who fall for phishing scams) and deals out serious punishment to the honest business owner. I predict we will see many small web-based business go under because of this. Another anti-entrepreneur blow from the capitalist elite.

Another way to look at this is 'Presumed guilty until innocence is bought.'

Intranet based applications anyone?

[brunes69]

This all sounds well and good, until you are asked to deploy and support intreanet-based applications on private IP address ranges, like the company I work for.

The UI for our product is web-based, and of course we prefer it be SSL encrypted, as it can contain sensitive information. But because the product is always deployed AFTER sale by our customers on some private IP address, with god-knows-what hostname, there is NO WAAY for us to provide them with a valid SSL cert. that will not pop up these annoying warning dialogs.

The problem is exasperated even more by the new IE7, which doesn't just provide a warning dialog, but a full page near-error message.

There is no way around these messages, aside from ample documentation. This is where the SSL standard falls FLAT ON ITS FACE. It is only acceptable for PUBLIC FACING, INTERNET BASED SIDES. It is TOTALLY UNACCEPTABLE for intranet based solutions.

Now, this really is not totally an SSL problem. The browsers are to blame as well. There should be a simple setting you can enable (and I would even go so far as to say it should be turned on by default), that excludes the need for SSL authentication on the private IP address ranges (172.16/16, 192.168/16, 10/8, etc. ).

Re:Intranet based applications anyone?

[modeless]

I maintain that encryption without authentication is a stupid idea even on intranets. There's nothing special about intranets that makes MITM attacks impossible. In fact they're easy with an ARP spoofing tool.

Encryption without authentication only defends against people who can eavesdrop but not perform MITM. Unless you have set up static ARP records throughout your network, anyone who can eavesdrop can also perform MITM and trivially break your encryption. Who then is encryption going to defend against? Nobody. It's a waste of processor cycles, and worse, it's a false sense of security.

Re:Intranet based applications anyone?

[kayditty]

This is where the SSL standard falls FLAT ON ITS FACE. It is only acceptable for PUBLIC FACING, INTERNET BASED SIDES. It is TOTALLY UNACCEPTABLE for intranet based solutions. Now, this really is not totally an SSL problem.

It is absolutely not an SSL problem. SSL is a cryptographic protocol; HTTPS is the secure web protocol (actually, I don't think there's an official name for SSL+HTTP).

well, I guess SSL may be partially responsible, but you make the implication that SSL was only ever intended for the web.

private IP address ranges (172.16/16, 192.168/16, 10/8, etc. )

You mean 172.16.0.0/12.

Re:Intranet based applications anyone?

[kayditty]

It is much stupider on an intranet. A man in the middle attack is much less likely on the internet (though neither impossible nor improbable), but atleast encryption sans authentication can actually do _something_ meaningful over the internet.

SRP6a would be better

[Myria]

SRP would go a long way to prevent phishing more reliably, and you don't even need a trusted authority (though one is recommended).

SRP is a password-based system, rather than a key-based system. SRP validates not just that the client knows the password, but that the server knows the password (hash), all the while not revealing anything useful to an eavesdropper or a man in the middle. It uses the password to establish a shared secret (session key) between the client and server for further communication.

It would help with phishing, because if the server you're connecting to doesn't have your password (hash), the logon attempt will fail without giving the phisher anything useful. SSL isn't enough for this, because phishers just get SSL certificates.

The weak point of SRP is establishing the password at account creation, and here SSL is important. Banks would go further and use out-of-band communication (phone, etc.) to help with account creation.

Web browsers don't currently support SRP, but supposedly the Firefox team wants to add it. An important part of such a feature will be making unfakeable dialog boxes so that novice computer users understand when it is safe to enter an important password. UI design means a lot.

paypal-reverify.com

[Anonymous Coward]

To make sure I was safe I tried to go to paypal-reverify.com, but the page wouldn't load. Can someone check that's it's working correctly so I can make sure my account details are verified and secure? I'm pretty sure I'm safe since I recently went to https://www.visa-secure.com/ and changed my password from "password" by adding a number 1 on the end -- since I'm told that putting 1 on the end of a word hopelessly befuddles all those hackers.

Maybe I'll just verify my account details by responding to email. That way there's no chance that hackers at a web site will be able to steal my information. I won't have to worry about a green lock at all, or anyone making it green with a hacker thing, because it won't go on the web thus there won't be any chance to grab anything.

Since the web is so insecure, maybe someone should come up with an alternative...except we already have one. We can just use email instead. I can't believe no one has ever thought of this before. No one will be able to steal anything because there won't be a web site to fake, and there won't be all that confusion about locks and yellow things and green locks, and that technical stuff.

Microsoft

[drDugan]

This orgnization represents what is wrong with the software industry today. On top of unfair business practices and anti-competative monopolistic bullying -- they:

* write insecure products that people cannot fix themselves
* delay patching their insecure products
* try to prevent SOA/REST from emerging quickly; relying on obscene vendor lockin for revenue
* build and use languages that promote and maintain poor programmming practices

They are the prototypical entrenched power monger, and they continue to pollute the industry with poor behavior, which is accepted only becuase they yield so much power with their cash.

Windows 2000 was their best product, everything else has just been a slow, painful death slide.

Re:There are many problems - some are legacy probl

[Ben Hutchings]

Every one of you who ever coded a browser to announce anything threatening about a site because a certificate was self-signed is complicit in a monumental scam

The purpose of a certificate is for a server (or less commonly a client) to "prove" that the public key it's presenting belongs to the entity that its peer intends to communicate with. If you don't know that you're using the right key, what's the value of encrypting? I agree that many CAs have weak verification processes, and since any CA can certify for any domain then the value of certificates is determined by the worst CA. However, a certificate by a known CA is still somewhat more trustworthy than a certificate by some random key about itself.

Re:Good UI idea, bad (but improved) cert idea

[Ben Hutchings]

One of the bad things about x.509 up to now is that it's all-or-nothing; the other side's identity is either completely trusted or not trusted at all.

This is because x.509 was designed for the Directory Access Protocol (x.500) which is entirely hierarchical and has no room for uncertainty or rival authorities.

Acknowledging that there is a degree to which the other side has been authenticated, and then showing this in the browser, is a step in the right direction.

This still says nothing about trustworthiness, though.

It's still unfortunate that they left the biggest weakness in the system, though. An identity is still only certified by one certifier. That's really dumb.

It's also inherent in x.509. As I implied, it's designed to have only a single root. In reality we have multiple roots, but validation of a certificate still has to lead to a single root CA. Divergence or cycles in the "trust path" will cause existing x.509 implementations to explode.

So the user then goes into their software and also sets Verisign to a low value. The user should only really trust people they have reason to trust. They probably wouldn't really delete Verisign from their list, but they'd set the trust level to very low.

I agree that this makes sense. But at present most users don't even understand the difference between the browser's security indicators (lock icon, yellow address bar, etc.) and in-page security claims (bullshit like Verified by Visa). I have no hope at all that users in general will be able to make sensible decisions about which CAs to trust.

I understand why Microsoft is willing to play along with the big CAs. I don't understand why the Mozilla, Konqueror, Safari, etc teams do.

The whole stupid system depends on global agreement as to which are the root CAs.

How do you trust a site?

[sowth]

I don't know about others, but having a valid key from a CA doesn't make me trust the site any more. I don't care if they have "levels" of trust. I look for a CA to verify the site is who they say they are and there is no man in the middle attack (supposedly).

I trust the site based upon what I know about the company behind it. If I don't know anything, I'll try searching for info about them before I buy.

The issues for me are:

1. Will the seller deliver the product I bought in a reasonable amount of time without hassle? Some companies are dishonest or just incompetent, the latter more common, so I need to know what pitfalls may exist while trying to do business with them.
2. Will someone intercept my CC and other info during the transaction? Encryption and a CA make this much more difficult, though problems with browsers and mistakes at the CA sometimes allow criminals to get around this.
3. Will the company themselves accidently leak my info? Insecure sites and bad company policy (letting too many emplyees see CC info) can let your CC# out into unsavory hands. Will they hold my CC info forever? The longer they hold the info in a database (especially one connected to their web site), the more likely a hacker or someone at the company may "help" themselves to my card's account. I hate those sites which insist upon keeping my CC# for "convenience". It doesn't take that long to type it in, and keeping it makes it easy if someone happens to somehow figure out my password (or a way to get around passwords) and send some merchandise to their address by charging me.

Re:There are many problems - some are legacy probl

[fyngyrz]

the purpose of a certificate is for a server (or less commonly a client) to "prove" that the public key it's presenting belongs to the entity that its peer intends to communicate with.

It can't "prove" any such thing. A simple security breach, or intended malfeasance on the part of the cert holder, and you're talking to someone else. The idea that it could prove such a thing more than half a second after it is issued is 100% illusion.

If you don't know that you're using the right key, what's the value of encrypting?

The same as it has always been: Limiting exposure of communications to the parties with the ability to decrypt the data. Nothing else. For instance, in the case of e-commerce, it limits the number of parties who get access of your credit card data.

However, a certificate by a known CA is still somewhat more trustworthy than a certificate by some random key about itself.

How so? It doesn't mean the identity is correct; it doesn't mean the location is correct; it doesn't mean ownership is correct; so what does it add? Both get your data encrypted just as well.

Now, if you're talking about adding value because CA certificates aren't subject to the scam where the browser scares the heck out of the client, and where the client is deluded by the marketing of said scams by the CAs, then I agree. That's my point. It's a scam.