Slashdot Mirror

Yes, there's a whole RFC series for Unicode labels in domain names, including advice to registrars for how to mitigate that problem. The ".com" domain itself is managed by Verisign, and they have a policy to address exactly that problem.

In many ways the guy owning the domain should have probably seen it coming and had a backup domain name?

The guy owning the domain should have seen it coming and placed a $300/Year REGISTRY LOCK on the domain so that not even the domain registrar would be able to make changes to it without Verisign calling up the registrant and receiving permission to temporarily unlock the domain for changes.

I thought the security of DANE relied on that of DNSSEC, and the security of DNSSEC was limited by the 1024-bit RSA zone signing key on the root zone until October of last year. The deprecation of 1024-bit RSA is why, for example, web browser publishers haven't added support for DANE.

Somewhere, D James Bidzos just got a massive boner.

Thanks, I have a free key fob from ETrade. Let me check if schwab would accept it and if quicken would handle it right.

Etrade, like PayPal, Schwab and many other consumer-oriented sites, actually uses a hardware token from Symantec's Verisign Identity Protection (VIP) ecosystem. At https://idprotect.verisign.com/learnmoretoken.v you'll see a picture with VIP tokens where one looks exactly like (except for branding) the free one you could have gotten from Schwab and the other looks exactly like the one you got from Etrade. Because Schwab also gives out VIP tokens you may need to make it clear that you already have a token and just want to enroll it to your account. When Schwab signed up with VIP they made it clear that they supported its goal of using one token across multiple sites http://www.securitiestechnologymonitor.com/issues/20060604/17672-1.html

Schwab actually gives Quicken, but not Mint, an interface that bypasses the token check. Convenient for you in that your Quicken usage won't be affected, but not as secure. I never used Schwab's iOS or Android apps so I don't know whether they enforce the token check on access through those interfaces like Etrade does. You'd think they should but its amazing how short sighted brokerages and banks can be about extending good security to their retail customers.

Seriously, self-signed certificates can only be verified by comparing them against a stored public key for being exactly equal.

So explain this.

(Hint: who signed that certificate?)

I don't know what percentage does, but you can check if your software does by attempting to connect to this site: https://test-sspev.verisign.com:2443/test-SSPEV-revoked-verisign.html

Verisign has this, and free to download. Works on Paypal, eBay, and a few others. Would be nice to see this on other sites too. http://vipmobile.verisign.com/

Do you have any evidence that registrars are accepting soft hyphens in domain names?

soft hyphens supposed to be eliminated in the Name Preparation phase.

The soft hyphen is being used by spammers to obfuscate their URLs in order to get past anti-spam rules.

This slashdot story appears to be misinformation and a plug for Symantec.

I wouldn't do that, since I suspect there's a big overlap in the group of vendors who go "nonsecurity issue" when it is one, and the group of vendors who would sue you if you post the "nonsecurity issue" publicly.

Maybe you could sell the vulnerability to one of those security sites, black, white or grey: http://blogs.verisign.com/idefense/2010/02/casablanca-buying-vulnerabilities-and-digressing.html

This actually isn't quite true. If you become a com/net registrar, most of the money goes to VeriSign (who controls the com/net registry). The registrar has to pay VeriSign roughly $7 per domain per year that they register. The 20 cents per domain you're thinking of is the ICANN fee, which definitely exists, but isn't the biggest cost. org/info is similar, but the money goes to PIR instead of VeriSign.

The registrars' profit margin is quite thin.

Source: http://www.verisign.com/domain-name-services/become-registrar/com-net-registrar/index.html

Tim Callan, vice president of product marketing at VeriSign, responds (in more detail) to these Black Hat presentations in his new SSL blogpost: https://blogs.verisign.com/ssl-blog/2009/07/busy_day_at_black_hat.php He fills some of the holes that Marlinspike and Kaminsky dug.

Well at a technological level, it's just a matter of fact that it is not necessary for the CA to have your private key. All they need to do their job is your public key, and something signed with your private key. When your public key successfully decrypts the signed message, they then know you possess the matching private key. Then they verify your actual identity credentials to whatever extent they want (has nothing to do with encryption), and bam, they can do their job: Attest that your public key does in fact belong to you.

Anyway, I don't know what sources said that the TTP/CA generates keys for you, but how about this page from Verisign on how to generate a Certificate Signing Request, which is what you send them in your application for a certificate. Notice how it explicitly states (and gives Linux command lines for) generating your own public/private key pair. You use it to sign your request, and there you go.

I honestly want to know why vendors don't use MSI.

For one thing, they might have an installer that works, so don't touch it. Or they might have to support users who don't have the latest version of Windows Installer installed.

I'd love to see Microsoft make compulsory MSI usage as part of their Windows certification programme.

I could try to verify it, but apparently one has to have a Winqual account to get the logo requirements, and you need a paid certificate from VeriSign to get a Winqual account. VeriSign won't issue certificates directly to individuals; the sign-up form requires a "company", and various PDFs that VeriSign makes available through the certificate application process imply that this means a corporation or partnership, not a mere DBA form.

Everyone needs to take a breath, and take a look at the CapOne web site. The certificate contains the correct URL for that page. The problem is NOT the SSL cert; it's the stupid Verisign seal thingy.

That Verisign seal thingy is coded to show the wrong sub-domain. Apparently CapitalOne created a seal for one sub-domain and inappropriately used it on a page in a different domain. They could do that because nothing the seal prevents it's use in the wrong domain. It won't even alert the user to an erroneous use.

That's the problem with the Verisign assurance seal. It assures absolutely nothing.

For yucks, create a Versign seal -- but pay attention to their rules!

VeriSign provides Warranty Protection to consumers to reimburse them for exposure to these types of risks. It can be found here http://www.verisign.com/repository/netsure/netsure2.html

Site owners (the ones paying the bills) have no incentive to demand that the CA be competent.

I completely disagree. SSL is all about trust, and the CA you trust for your site's cert does matter. There's only so much a CA can practically do to establish your (corporate) identity, but that's what you trust them to do every time they are asked to issue a certificate in your name. It's not rocket science, this is a basic level of trust that everyone needs. We expect, and trust ANYONE who handles our personal information to properly, consistently verify our identity.

A better system would have the end-user pay someone they trust to identify the site; they are directly paying for the identification service and can take their business elsewhere if they get crap service.

What?? Let me get this straight... you want to pay for a whitelist(s) of the Internet? OK, while you're shopping, I have a nice bridge you might be interested in.

Mapping to real-world identities is a separate issue (only provided by "extended validation" or whatever certs due to browser UI issues), and is (1) rather expensive because you need people involved to look at paperwork and such and (2) mostly isn't needed, because you'll generally find IRL groups' sites by communication from those groups (eg, my electric bill has the electric company's URL printed on it, I don't need to look them up in google and then verify that I got pointed to the right place).

1. The whole point of a CA is for them to verify who you (site owner) are. People are already involved to look at paperwork. To change a POC in our existing system even requires you to fax paperwork to them on company letterhead. If they didn't do that already, then what is the point of requiring end users to trust them? If they fail to do this, then fire the CA, delist them, stop trusting them. Are CA's perfect, no. Could we use some better standards, or maybe regulation to ensure they enforce certain security best practices, possibly. We got EV certificates without regulation.. a small UI improvement (somewhat standardized at least), better checks, legal ID, physical presence (they have a better method than the phone book reverse lookup check I guess?), URL ownership, etc, BUT only for a new, more expensive, OPTIONAL class of certificates. Are Internet users clamoring for more regulation, hell to the fsck no. It will eventually be required to properly tie up loose ends in a trust based system I think though.
2. I will repeat again what you said, so it has more time to sink in.
"you'll generally find IRL groups' sites by communication from those groups (eg, my electric bill has the electric company's URL printed on it, I don't need to look them up in google and then verify that I got pointed to the right place)."
Everyone will use a search engine for the dumbest things you can possibly imagine at some point in their life.
Getting to the right URL is already assumed when dealing with MITM attacks.
Going to the wrong URL is NOT something a CA is in a position to prevent. - EV helps, but if normal certs are still trusted then bad URLs with normal certs still are too, so WTF is the point? Well.. besides CAs wanting more money.

If browser vendors adopted an EV type UI for all certificate "tiers", then our current system could help against fraudulent URLs with valid SSL certs.
The problem then is we'd then have no way of distinguishing the extra checks CAs are doing for EV without over complicating the UI. WHY do we need to distinguish those extra checks you ask? Because CAs want mo' money, and part of that is driving end user demand for expensive certificates.

The MITM is just a UI issue with our current certificate system.
The problems we have with the UI are because CAs use inconsistent identity verification and we stupidly tied the UI to that. We SHOULD be able to use self signed c

Go ahead and accuse me of not being libertarian, but yes, I think making and enforcing standards for CAs is a good role for the government.

Governments have a vested interest in keeping things insecure; they want MitM to be achievable, and making CAs answer to government means you can't trust them as introducers. Go ahead and have government-regulated CAs, if you want, but we need the capacity to have multiple signers for any identity so that we don't depend on that inevitable single point of failure.

I would never put my money in an unregulated bank, or send premiums to an unregulated insurer, or go to a back-alley doctor.

Switch to OpenPGP and you have a situation analogous to using the best bank/insurer/doctor. If one is untrustworthy, the other signatures remain. No government can possibly match that level of integrity. But they could become a part of it.

Then again, CA-signed certificates also suck. I've already written about it here, so I won't reformulate the problem in this post, but I'll quote the most relevant part:

---

The problem, then, is that this implies that you need to trust Verisign and Thawte to properly validate all the certificate requests that they get—people in an extremely large, bureaucratically weighed-down enterprise that process thousands of certificates daily using automated processes. What are the chances that they wouldn't let one single mistake slip through, and issue a certificate to a cracker for a site that he does not own? The problem does not end there, however: The certificates pre-installed on new PCs are not limited to Verisign and Thawte. They commonly ship with the certificates of around 50 different certificates organizations. Even if you feel secure in trusting Verisign and Thawte (which you should not, but more on that later), what are the chances that all of these can be trusted to consist entirely of incorruptible people and flawless processes? And, even if they did, what are the chances that all of them are completely secure and cannot themselves be cracked to produce faux certificates? For this reason alone, I, for one, would consider the entire process flawed and untrustworthy, and I would implore you to do the same. Therefore, Haven and Hearth uses its own, self-signed SSL certificate, bypassing the certificate authorities. To further clarify our stance, the following three points of policy are noteworthy:

• I do not want to convince you to distrust people. This is a problem of statistics; it would be almost weird if, somewhere in any of the many organizations whose certificates are installed in browsers worldwide, there did not exist anyone who was untrustworthy or just one computer system which is crackable, and the system is designed in such a way that just one is enough to break it.
• Sure enough, there have not been many major security breaches through this route (though it is not unheard of, either), so you might think that I am merely being alarmist, but I would still argue that the flaws in the system is enough reason to boycott it.
• Last, but not least: As I mentioned above, the certificate authorities more often than not charge quite obscene amounts for their services, which emanates an attitude that "The web is for corporations, not for individuals"; a statement that we resent.

But hold on, there is more to this. You may have read the preceding paragraph and still thought it all right to trust all these diverse organizations. However, you really should not: it is well documented that Verisign actively produces faux certificates for various purposes, especially for law enforcement agencies, so that they can perform MITM attacks. You can see Verisign's own home page if you doubt it. What Verisign's faux certificates mean in practice, is that their holder can impersonate any web site, to listen to the traffic between them and their visitors, modify their content arbitrarily and catch any and all sensitive information. And by that, I really mean any web site, not only those with certificates signed by Verisign in the first place. See, when the browser performs its certificate authenticity check, it checks the web site's certificate against any of its installed certificate authorities, and it does not even warn you if the web site's certificate has changed since the last time you visited it, as long as it is signed by just one of the certificate authorities it knows of. Of course, it is not only Verisign which is bestowed with this power – any of the certificate authorities can do th

How do digital signatures allow easy harvesting of email addresses?

Certificates must be centrally stored or related to a trusted central authority. With this, you only have to break that central authority to get all the valid e-mail addresses. In addition, if all e-mail had to be signed, then people wouldn't be able to use throwaway e-mail addresses as easily, so every "give us your e-mail" would mean that a valid e-mail address was being harvested.

Few organizations on this planet have the resources to brute force a valid bogus digital signature, and no one can do it on the sort of scale you'd need to send spam.

You are thinking about forging e-mail, which isn't the problem. Spam could have a valid signature without being from someone you know. Like current spam and phishing, it could be from someone you might know.

Easy to obtain, in that we really only need the mail server admins to cooperate, then everyone (who wants to get their email) will play along pretty damned quick.

Once you finish that "easy" task, could you get to work on the trivial problems of a portable fusion reactor, transporter technology, and faster than light travel?

Armies of worm riddled broadband-connected Windows boxes - Can spam as much as they want, it will never get read.

The bot that controls a Windows machine probably also would be able to control the certificates the user had for sending e-mail. Thus, signed spam from people you trust.

Joe jobs and/or identity theft - Would require either knowing their private key, or even in the easiest case, physical access to their machine.

Cruise on over to Verisign and see just how easy it is to get a certificate with an e-mail address that isn't yours, and Verisign is one of the better at checking it. Also, read what I wrote about bots infecting the machine.

I don't want the government reading my email - So add full-message encryption basically for no extra work. And they can read your email now, so how would this make it any worse?

Because today there isn't a central certificate authority that is required to be used by everyone sending e-mail. This idea would make that a reality. That CA would have all the private keys for all the certs in a one-stop shop for the government. Encrypting wouldn't do any good, because it would be done using one of the same keys that was available in the CA.

It would be cost-prohibitive for a phone company to maintain connections to every company they want to exchange SMS with. Instead, they select one of the several companies that maintain inter-carrier messaging networks to deliver this traffic for them. These companies include VeriSign, Syniverse, and Sybase 365. Which carriers you can exchange SMS with depends on which of these vendors your carrier has selected. In general, while they all have two-way reach to the major carriers internationally, each vendor has a different profile of smaller international carriers and countries in their portfolio.

Obviously, self signing is meaningless for anonymous strangers. It works just fine for you and your friends/colleagues, but not for anyone outside your immediately trusted group.

What are the free alternatives to VeriSign's hefty fees? Some kind of community effort to create trust, much like PGP key signing seems like it would be a good solution.

Besides being expensive, it looks like any shmo can register with verisign and then conduct all sorts of questionable practices behind their cert. It doesn't look like there's any sort of vetting in the process. I didn't complete the signup process, but it looked like once they had my money, they'd send me a certificate. While the connection is secure, that doesn't tell me a darn thing about what they are going to do with my data, or weather or not they're going to try something malicious.

At this point, it would be nice for some organisation to just start signing PGP keys when you fax them a driving license or something, the equivalent to a CA but for PGP keys which traditionally needed huge effort to figure-out if the key matches the person.

See, e.g., http://www.verisign.com/authentication/individual-authentication/digital-id/index.html or look for similar services from a CA you trust.

Would be bad if browsers don't play well with wildcard certs.

I think you have a significant misconception here.

Encryption without proper authentication of both parties (usually SSL cert to authenticate the server and login/password to authenticate the user) is worth almost nothing. What good is your encryption if the users connecting to your service for the first time have no way to make sure that the site is not a scam? Their passwords may very well get harvested by a malicious third party. And what this encryption buys you then? Nothing.

Well, I've read some of your posts, and I can see that you aren't concerned with those attackers. Citing yourself:

• "... non-profit groups, which will never have issues with domain typo scammers ..."
• "... applications that don't need this level of identity verification ..."
• "... academic and non-profit sites that need encryption ..."

Let's connect the dots. You have a site that will never have issues with scammers (you say domain typo, but it seems you're completely unaware of the myriad of other attack scenarios that PKI successfully prevents), hosting application that doesn't require high level of server's identity verification (which is the purpose of the SSL server cert), but your clients somehow need encryption.

Tough noodles! You should realize that before FF3 you did it all wrong! Since the users saw a click-through warning, which they blissfully dismissed, the whole encryption you made was a waste of server's and clients' CPU cycles and wasting of electrical energy. Someone could direct them to a malicious proxy and they'd see an identical warning which they would happily click through and then use your site, but their login and password would already be in the wrong hands.

But if you're not concerned with such attackers, then simply turn encryption off! It's not good anyway, and it's a waste of time (your and your peers) and resources.

You're proposing an alternate low cost/low verification level CAs. To get around this problem. Are you fully aware that when you lower the financial and organizational barriers to obtaining a certificate, you open a large can of worms?

Suddenly not only non profit organizations, but all the cheap scammers can afford obtaining dozens of throw-away, fully valid certificates to perform their phishing scams. This time users won't see any warning, but a nice shiny lock icon in their browser that makes them feel safe and warm while they submit their financial details to a malicious site somewhere in Russia. Is this really what you want?

Realizing your proposal would really beat the purpose of this whole system - the public key infrastructure, the certificates and their chains, the encryption and SSL handshake, all this would cease to have any usefulness and would become dead weight.

True, there's one interesting potential solution that could be plugged into the existing infrastructure.

It's called a trust web and the likes of CAcert operate on a similar fashion. However, this idea has not been tested in a real world scenario where successfully attacking the system would promise significant financial gains (e.g. by masquerading as bank sites), unlike the X.509 system we have in place now.

It's uncertain whether a trust web would withstand concerted distributed attacks on its trust propagation from the criminal underground.

Yes, there were some high profile problems with the current X.509 infrastructure (like the Verisign-Microsoft Authenticode fiasco. But they were quickly plugged - look at the advisory I've linked to. This is where the cost of the certificate comes from. The issuers actually verify the identity of the requestor, and if they fail to do this from time to time, they still have backup systems in the form of fraud detection departments. That's why obtaining a certificate cannot be free and if it was free, that certificate wouldn't actually certify any useful information.

You mean the VeriSign - Microsoft authenticode fraud ? Or some other, newer screwup that I haven't heard of?

When issuing a certificate, Verisign supposedly (yes, I'm trying to be realistic) checks that the requesting organization is still in business, that it has rights to the domain name, that the request comes from someone who works for the organization, that the corporate contact is aware of the certificate request, that the technical contact is authorized to receive the certificate and they check the domain name for similarity (phishing-wise) to some established brands names.

I still highly doubt that with free or cheap certificates you would ever get that level of verifications. Much more likely the cheaper the certs, proportionally the more likely they would be to belong to malicious parties.

This idea is very interesting indeed. If I understand you correctly, you're proposing to move the web of trust PKI known from PGP/GPG to the arena currently occupied by X.509 and hierarchical PKI, right?

This could really lift the burden of managing the complexity of trust, life cycles, secure storage of central CA private keys from the CA. I can see that even Verisign has significant problems with that. Their certs don't seem to specify OCSP URLs yet, and they had some scaling problems with CRL distribution points. Distributing the PKI could solve lots of problems and the cost of maintaining that infrastructure would be more evenly distributed, too, which would lead to practically free certification (with some hidden costs, obviously, mostly in time and effort of participating parties).

There are potential problems here that I see, though.

Adapting the web of trust idea to the web for the HTTPS protocol would need preparing and constantly tweaking some variables. E.g. above what level of trust should Firefox's address bar turn yellow? How do you communicate the level of trust of the given site to the user so that he's likely to understand it correctly?

And how do you prevent coordinated abuse of that system? Note that the OpenPGP's web of trust has never been tested in the situation where successful attacks would be so highly rewarded as they currently are in the realm of HTTPS/X.509 (think phishers and other scammers).

For example, a network of criminals might recruit some number of homeless people from large cities around the world. These people have their IDs, and are willing to do anything for some money they need to spend on food/alcohol etc. It's quite common for those homeless with nothing to lose to get recruited, shaven, dressed and sent into bank offices to open small disposable credit accounts in their own names using their IDs, only to hand all the money they can get to their recruiters who give them some small percentage which they are going to quickly spend anyway. Then they run into trouble with law enforcement when it turns out they cannot pay, but hey, they didn't quite realize what was this all about, they weren't quite sober anyway.

Now the criminals might find it beneficial to recruit those people to go into key signing parties and obtain verified signatures on their keys/certificates practically for free (well, say one cheap wine per signed key). When they collect the necessary amount, they cross sign those keys to gain high enough level of trust and set up a large scale phishing site. They make gobs of quick cash before the web of trust reacts to the manipulation, which can require a significantly long time in a loose informal structure like this.

Would the idea that you propose be resilient against concerted efforts like this one?

I googled around earlier to try to determine whether these are VeriSign VIP devices. If so, that'd be great -- they'd interoperate with PayPal and eBay and VeriSign's OpenID provider and anyone else who either supports OpenID or signs up for VeriSign's program.

Making tech-happy people carry around more than one OTP device would be a real shame, so I'll be disappointed if more word on these comes out and it turns out that they don't interoperate.

Now, I understand perfectly well that Verisign and its brethren have made a huge industry out of scamming consumers into thinking that identification is indeed something that a certificate provides; but that is marketing illusion and nothing more. Hokum and hand-waving.

I disagree 50%. In practice, this is correct, but in theory it is not.

Theoretically, the CA is actually checking the identity of the orgs they sell certs to. Most actually do this to a limited extent.

Also, each of the CAs keeps a revocation list for certificates that got out of reach. In order for someone to use the certificate illegitimately, they have to gain control of the domain name *and* the certificate -- or simply the web-server I suppose.

If no major security breach is *currently* in progress, but one happened in the past, theoretically, you could simply revoke the certificate and get a new one.

The revocation works, but the problem is that nobody actually checks the revocation lists. I was going to link to it, but presently I can't even find the CRL for verisign...

CRL (knowledge)

Perhaps I'm just wrong and the CRL is built into my browser... I don't think so. I seem to recall actually clicking on a bunch of them to tell firefox to go check them nightly.

Yeah, in ff3 it's prefs->advanced->encryption->[revocation lists] -- mine is empty. Heh. Fat lotta good that does.

At my company, we use three different providers depending on the need.

Client Facing
We use Verisign for anything a client will interact with since we can use the Verisign Secured Seal on any web content on our site. Our studies have shown a percentage of our users actually know of the Versign secured logo and helps to assure them of the security.

Non-client Facing
We use Thawte certificates since these are much cheaper than Verisign, and are fully compatible with most browsers/mobile devices.

QA/Dev Servers
We use GoDaddy for internal/external tests and projects. They are cheap and quick, which makes them useful in a non production environment.

At my company, we use three different providers depending on the need.

Client Facing
We use Verisign for anything a client will interact with since we can use the Verisign Secured Seal on any web content on our site. Our studies have shown a percentage of our users actually know of the Versign secured logo and helps to assure them of the security.

Non-client Facing
We use Thawte certificates since these are much cheaper than Verisign, and are fully compatible with most browsers/mobile devices.

QA/Dev Servers
We use GoDaddy for internal/external tests and projects. They are cheap and quick, which makes them useful in a non production environment.

There are three points of contention:

(1) You must have your application signed before it will run on any cell phone,
(2) Your application must be delivered via the Apple iTunes store, and
(3) Your usage of the beta version of Apple's development kit subjects you to an NDA.

Well, the NDA part of the beta program struck me as a little odd, as it takes about no effort for any idiot to sign up and download the SDK for free--however, this seems to be a standard tactic by Apple for all its beta SDKs. The NDA will be gone, however, by the time the SDK is out of beta--so the whole "you must sign an NDA and that is incompatible with the GPL" thing will be gone by summer.

So what is left is the fact that you have to sign your application before it will run on the iPhone.

As someone who has written cell phone software before, I can tell you that Symbian and Windows Mobile also require application signing before allowing your programs to run on their platforms. It's very common in the cell phone industry to use certificate signing--and at $99/year, Apple is the cheapest to obtain a signing key. Further, from the sounds of it, by the time the SDK goes out of beta, anyone with $99 can get a signing key and sign as many apps as he wishes. (By contrast, for Windows Mobile you pay VeriSign $350 for 10 signing events, meaning you can only sign 10 applications or different versions of the same application. (Actually a signing event means you sign one executable.) Symbian is even more of a pain in the neck. And let's not talk about Android until real Android-based phones start showing up on the market and we learn what sort of package signing requirements the cell phone manufacturers impose on Android applications.

While I appreciate the need for authors to fill column space in order to get paid, it seems to be a little early to start complaining about GPL incompatibility and pointing the fingers solely at Apple because you're too lazy to compare and contrast with the other mobile operating systems out there.

There are three points of contention:

(1) You must have your application signed before it will run on any cell phone,
(2) Your application must be delivered via the Apple iTunes store, and
(3) Your usage of the beta version of Apple's development kit subjects you to an NDA.

Well, the NDA part of the beta program struck me as a little odd, as it takes about no effort for any idiot to sign up and download the SDK for free--however, this seems to be a standard tactic by Apple for all its beta SDKs. The NDA will be gone, however, by the time the SDK is out of beta--so the whole "you must sign an NDA and that is incompatible with the GPL" thing will be gone by summer.

So what is left is the fact that you have to sign your application before it will run on the iPhone.

As someone who has written cell phone software before, I can tell you that Symbian and Windows Mobile also require application signing before allowing your programs to run on their platforms. It's very common in the cell phone industry to use certificate signing--and at $99/year, Apple is the cheapest to obtain a signing key. Further, from the sounds of it, by the time the SDK goes out of beta, anyone with $99 can get a signing key and sign as many apps as he wishes. (By contrast, for Windows Mobile you pay VeriSign $350 for 10 signing events, meaning you can only sign 10 applications or different versions of the same application. (Actually a signing event means you sign one executable.) Symbian is even more of a pain in the neck. And let's not talk about Android until real Android-based phones start showing up on the market and we learn what sort of package signing requirements the cell phone manufacturers impose on Android applications.

While I appreciate the need for authors to fill column space in order to get paid, it seems to be a little early to start complaining about GPL incompatibility and pointing the fingers solely at Apple because you're too lazy to compare and contrast with the other mobile operating systems out there.

Verisign also isn't increasing just to increase. They are actually losing money in total, which will be corrected by the end of this year(by divesting- not 7% whatever).

They are increasing their network/server/node count by a factor of 10 in 2 years time. I'm sorry, but 7% ain't squat when you're are required to have 99.97% uptime for planet Earth. The contract is up for renewal in a few years. So will you feel better when verisign competes with everyone in the World, and still wins it hands down? This is not something you can compare to a lemonade stand. It's a utility, that absolutely must stay up or you all die. Including this website and your rantings in the wilderness.

http://www.verisign.com/information-services/ATLAS/Project_Titan/index.html

They aren't screwing us. If you want to see screwed, give it to France or China.

Symbian for publishing costs $250:
http://www.verisign.com/products-services/security-services/code-signing/symbian-content-signing/

I'll give you a more conclusive answer:

http://www.verisign.com/information-services/naming-services/com-net-registry/page_002166.html

This is the list of all companies which Verisign has on record as being allowed to add directly to the .com and .net registries. Gandi is listed (under the name Gandi SARL) as an accredited registrar.

If the data is anonymous, how do you verify its integrity?

If the identifier for a block of data is a hash of the data, you can verify its integrity without knowing a hill of beans about who or where it came from.

If the link pointing to a secured, anonymous site is a hash of the site's public key, you can verify that the site you're talking to can use the corresponding private key, which is the same thing SSL buys you. The high-priced "secure site certificates" just certify that the owner of $DNS_NAME also owns $PUBLIC_KEY; if you got a self-authenticating link from another web site you trust, the level of assurance is comparable.

If the algorithms that underpin this stuff are broken then the whole digital security house of cards is toast, including "High Assurance SSL Certificates" (Now with green pixel paint for your clients' address bars! Sorry, cross-site scripting protection not included.)

The RSA SecurID tokens are completely different, according to VeriSign, and will not work with their PIP system.

If you want to buy this "FOB", which is functionally identical to RSA's SecureID token, you can purchase it from PayPal, that calls it "Security Key" for an introductory flat $5, no shipping, or from VeriSign, that calls it "VIP Security Token" for $30 plus $6 shipping.

He's that dude --> http://blogs.verisign.com/websecurity/

I meant verisign, sorry (things have moved around since I used to work in web hosting in the late 90s).

http://www.verisign.com/information-services/naming-services/com-net-registry/page_001052.html

But now we have a situation where by posing as a registrar, they can speculate at pennies per year per domain -- which makes it economic for them to sit on vast farms of domains.

You might be interested to know that registrars pay USD6.42 for a .com domain name (USD4.85 for a .net domain name) from Verisign. So a 1,000,000 domain-name portfolio doesn't come cheap!

Setting up a registrar requires a significant up-front security (either actual cash or letter of credit) equal to the number of anticipated monthly registrations x the number of years x the USD registration fee. In addition, you must pay ICANN about $10,000/year for accreditation, and demonstrate at least USD70,000 in working capital. It is not a trivial undertaking.

What many speculators do is "test-drive" domains by taking advantage of the 5-day grace period that Verisign allows before a domain name must be paid for. Even then, a registrar will pay $6.42 to continue to hold onto a domain after the grace period.

You've got a point, but the Constitution does limit the feds' power, and a common-sense reading of it tends to place that boundary far below the current level of power being exercised. If you uphold the spirit (and theoretically, Ron Paul would), then the feds won't have the ability to outlaw encryption. Some people fear we might head that way (I'm not so sure).

Conspiracy theories: the rather conspicuous lack of trustworthy end-to-end crypto in everyday products (e.g. cellphones, "popular" internet clients, etc) is caused by government pressure (if not statute), somewhere. Verisign hints that they assist in MitM attacks by issuing bogus X.509 certs in accordance with CALEA (?!). Uphold the constitution, and all of this goes away.

So while such a president+congress might not care if Google snoops on you, they would also get the fuck out of the way and allow defense against snooping to become commonplace. (That is, if you buy into my conspiracy theory that government is the cause of this suspiciously lightly deployed, yet very old, technology.)

Most everyone writing online recommended using S/MIME instead of GPG,

S/MIME is quite a bit worse, simply because an identity can only have one certifier. At least with OpenPGP, you can get multiple certs, thus requiring a conspiracy in order to do a MitM.

Whoever recommended you use S/MIME instead of GPG, probably considered security to be a very, very distant second priority, compared to some other value (probably Mail.app compatibility; I have that program here at work, and I don't see any OpenPGP support in it).

The question I could not answer is how trustworthy is this Thawte-issued "certificate"?

That's indeed a problem. You don't know. You probably don't know the name of a single person in that company, and you don't know their policies for protecting their signing key. Of course, at least you're asking (which is extremely cool and wise), but you're not going to get an answer.

For all you know, they might be vulnerable as Verisign. And with S/MIME, that means there is a single point of failure which can allow MitM.

Required reading here.

Look at how gleefully they advertise exploiting their trusted thiry-party (SSL Certificate Authority) status.

I think we need to consider switching all our browsers to a more trustworthy CA.

Then you have someone at Verisign (or some other trusted provider) who can read all of the worlds sensitive data.

And they actually do. Verisign now does for-hire intercept service. And CALEA has just been expanded to cover data links, not just voice:
http://www.verisign.com/products-services/communications-services/connectivity-and-interoperability-services/calea-compliance/lawful-interception/index.html

This is a service targeted at your ISPs and phone cos that have to be able to spy on you. When nasty business get becomes a huge job... outsource it to the one holding the most keys.

PGP, anyone?!

...but my opinions are purely my own and I speak for myself, not my employer.

Anyone "in the industry" already knows about iDefense and their Vulnerability Contribution Program, so you obviously are not. iDefense isn't the only company that posts challenges or pays for vulnerabilities. Perhaps you should read up at http://labs.idefense.com/vcp/

It is not a marketing ploy or publicity stunt. The iDefense business is about selling internet intelligence, not pushing anyones software. This is an initiative to discover critical vulnerabilities in those applications so that they can be patched. Nothing more. If you believe that BlackHats aren't already looking for vulnerabilities in those applications then you need to get a clue stick and start whacking yourself over the head with it. The VCP gives WhiteHats (and GreyHats) incentive to find them first, so that they can be dealt with responsibly rather than end up a zero-day exploit.

The applications chosen are old and considered robust. That's why they form the backbone of the internet in the first place. And also why a critical bug in them could bring the internet to its knees. Any QA engineer worth their salt will tell you that the first place to look for a bug is in software that has shown itself to be buggy - and that applies at whatever level you want to consider - block, function, class, library, application or suite. sendmail anyone? Bind? If you believe that there are no more bugs to be found then you are likely mistaken. I think iDefense will (gladly) pay out on more than one of these applications during this challenge.

The terms to the challenge are fairly standard and non-onerous, and I think you're reading too much into them. The version restriction is purely because no-one is interested in vulnerabilities in Apache 1.4, nor IIS 5 anymore. The additional software clause is again non-onerous. Your example isn't valid as a vulnerability in e.g. vBulletin would be a vulnerability in vBulletin, not a vulnerability in apache itself. Now if you could make a well configured mod_php fall over and clobber the box without requiring badly written php pages installed, then I think they'd be interested in that. The term about having not previously reported it is so that the vulnerability can be labelled iDefense-exclusive, adding value to the intelligence report.

Ask yourself where the iDefense business model is if there were no vulnerabilities in any software. The entire business is built on the premise that there are vulnerabilities and that there are customers willing to pay for intelligence reports about them, and vendors willing to receive notifications about them. iDefense would love to pay out on all of those prizes.

iDefense do not sell any software, so there is no reason to say "We're more secure than those other guys". They sell actionable internet intelligence. http://www.verisign.com/Resources/Managed_Security _Services_Tours_&_Demos/security-threat-video.html shows one way that this intelligence is used.

Frankly, maybe you should stick to Walmart as you don't seem to know much about the internet security business. I doubt that you could make a living in it. You should get your patch installed.. :)

(BTW - for all the slashdot VeriSign haters out there - after over a decade in the workforce with multiple employers, I can honestly say that I have never worked for a company so committed to helping customers solve problems. Every engineer I work with is dedicated to making the internet a better, faster, safer internet, and I work among extremely smart people who have respect, integrity and drive.
So the company implemented a RFC1034- and RFC1035- compliant service a few years back before pulling it after customer feedback. Get over it already.)