Dan Kaminsky's Blog

March 18, 2012 Dan Kaminsky 18 comments

MS12-020, a use-after-free discovered by Luigi Auriemma, is roiling the Information Security community something fierce. That’s somewhat to be expected — this is a genuinely nasty bug. But if there’s one thing that’s not acceptable, it’s the victim shaming.

As people who know me, know well, nothing really gets my hackles up like blaming the victims of the cybersecurity crisis. “Who could possibly be so stupid as to put RDP on the open Internet”, they ask. Well, here’s some actual data:

On 16-Mar-2012, I initiated a scan across approximately 8.3% of the Internet (300M IPs were probed; the scan is ongoing). 415K of ~300M IP addresses showed evidence of speaking the RDP protocol (about twice as many had listeners on 3389/tcp — always be sure to speak a bit of the protocol before citing connectivity!)

Extrapolating from this sample, we can see that there’s approximately five million RDP endpoints on the Internet today.

Now, some subset of these endpoints are patched, and some (very small) subset of these endpoints aren’t actually the Microsoft Terminal Services code at all. But it’s pretty clear that, yes, RDP is actually an enormously deployed service, across most networks in the world (21767 of 57344 /16′s, at 8.3% coverage).

There’s something larger going on, and it’s the relevance of a bug on what can be possibly called the Critical Server Attack Surface. Not all bugs are equally dangerous because not all code is equally deployed. Some flaws are simply more accessible than others, and RDP — as the primary mechanism by which Windows systems are remotely administered — is a lot more accessible than a lot of people were aware of.

I think, if I had to enumerate the CSAS for the global Internet, it would look something like (in no particular order — thanks Chris Eng, The Grugq!):

• HTTP (Apache, Apache2, IIS, maybe nginx)
• Web Languages (ASPX, ASP, PHP, maybe some parts of Perl/Python. Maybe rails.)
• TCP/IP (Windows 2000/2003/2008 Server, Linux, FreeBSD, IOS)
• XML (libxml, MSXML3/4/6)
• SSL (OpenSSL, CryptoAPI, maybe NSS)
• SSH (OpenSSH, maybe dropbear)
• telnet (bsd telnet, linux telnet) (not enough endpoints)
• RDP (Terminal Services)
• DNS (BIND9, maybe BIND8, MSDNS, Unbound, NSD)
• SNMP
• SMTP (Sendmail, Postfix, Exchange, Qmail, whatever GMail/Hotmail/Yahoo run)

I haven’t exactly figured out where the line is — certainly we might want to consider web frameworks like Drupal and WordPress, FTP daemons, printers, VoIP endpoints and SMB daemons, not to mention the bouillabaisse that is the pitiful state of VPNs all the way into 2012 — but the combination of “unfirewalled from the Internet” and “more than 1M endpoints” is a decent rule of thumb. Where people are maybe blind, is in the dramatic underestimation of just how many Microsoft shops there really are out there.

We actually had the opposite situation a little while ago, with this widely discussed bug in telnet. Telnet was the old way Unix servers were maintained on the Internet. SSH rather completely supplanted it, however — the actual data revealed only 180K servers left, with but 20K even potentially vulnerable.

RDP’s just on a different scale.

I’ve got more to say about this, but for now it’s important to get these numbers out there. There’s a very good chance that your network is exposing some RDP surface. If you have any sort of crisis response policy, and you aren’t completely sure you’re safe from the RDP vulnerability, I advise you to invoke it as soon as possible.

(Disclosure: I do some work with Microsoft from time to time. This is obviously being written in my personal context.)

Categories: Security

February 26, 2012 Dan Kaminsky 11 comments

So one of the core aspects of my mostly-kidding-but-no-really White Hat Hacker Flowchart is that, if the target is a web page, and it’s not running on your server, you kind of need permission to actively probe for vulnerabilities.

Luckily, there are actually a decent number of sites that provide this permission.

Paypal
Facebook
37 Signals
Salesforce
Microsoft
Google
Twitter
Mozilla
UPDATE 1:
eBay
Adobe
UPDATE 2, courtesy of Neal Poole:
Reddit (this is particularly awesome)
GitHub
UPDATE 3:
Constant Contact

One could make the argument that you can detect who in the marketplace has a crack security team, by who’s willing and able to commit the resources for an open vulnerability review policy.

Some smaller sites have also jumped on board (mostly absorbing and reiterating Salesforce’s policy — cool!):

Zeggio
Simplify, LLC
Team Unify
Skoodat
Relaso
Modus CSR
CloudNetz
UPDATE 2:
EMPTrust
Apriva

There’s some interesting implications to all of this, but for now lets just get the list out there. Feel free to post more in the comments!

Categories: Security

February 20, 2012 Dan Kaminsky 4 comments

For your consideration. Rather obviously not to be taken as legal advice. Seems to be roughly what’s evolved over the last decade.

Categories: lulz, Security

February 19, 2012 Dan Kaminsky 9 comments

So, one of my goals for 2012 has been to write quite a bit more — more code, and more long form analysis. So far, so good.

Doesn’t mean it’s all going to be about security, or even that it’s all going to be all that serious. My whole #Protolol thing worked out pretty amusingly…and so, here’s #nerdflix.

LOL. Some highlights. I can’t even imagine the horrible punnery I’m going to wake up to.

UPDATE 1: Apparently at some point #nerdflix was trending worldwide? It’s certainly taken San Francisco by storm

Anyway, here’s more.

Update 2: Also, Germany. This is not surprising.

---

@dakami: Memory Resident Evil
@dakami: Driving Miss Daisy Chain (h/t @wadebaker)
@dakami: Raiders of the Lost ARP (h/t @quadling)
@dakami: –wx—— (h/t @ennor)
@AtheistHacker: A Beautiful BIND
@RySub Desperate house wifi’s
@JGoldOrlando: no SALT
@johngineer: Ohm Alone
@kickfroggy: I Now Pronounce You PCI Compliant
@kickfroggy: There’s Something About Mary’s Code
@KrisPaget: Full Metal Packet
@l0qii: Beverly Hills Pcap
@marshray: Batman Returns-into-libc
@mratzlaff: Extremely pwned and Incredibly hosed
@otanistudio: ~/alone
@otanistudio: HTML5 Gordon
@plaverty24: Born on December 31, 1969
@redtwitdown: The Kaminsky Code (cc @dakami)
@wadebaker: Gone with the rm Memorable line: “frankly Scarlet, -rf”
@Walshman23: Girl, Interrupt-driven
@jadedsecurity: Apache Down
@chenb0x: The Netbook
@manzuik: Whitehats Can’t Code.
@afabmedia: Magnum, 3.1415926535897932384626433832795028841971693993751058209
@felipeLvalero: RT @Mackaber: RT @Voulnet: Despicable WindowsME / Lol
@0x17h: Gone with the Windows
@vogon: @dakami The SHA-1 Redemption
@vogon: @dakami 1U Over the Cuckoo’s Nest
@ThemsonMester: Oceans 802.11
@enriquereyes: 500 days of evaluation period
@a_r_w: The TEMPEST (staring Van Eck)
@marshray: Batman Returns-into-libc
@marshray: The Bitcoin Miner’s Daughter
@gbrunkhorst: The Little Endian in the Cupboard
@bm_: RT @_jtmelton: @dakami Lost in Machine Translation
@kickfroggy: Paul Blart: Mall CISSP << lol
@0x17h: The Deprecated
@0x17h: All About Eve Online
@afabmedia: So I Married a VAX Murderer
@infojeff: Pink Floyd The Wall of Sheep
@jdunck: Referer never dies /cc @kevinmarks
@kickfroggy: Fast Times at 802.3bg
@kickfroggy: How to Train Your User
@liambeeton: Firewall Club
@longobord: Schindler’s Linked List
@mfukar: reinterpret_cast Away
@obscuresec: Inglorious Hackers
@obscuresec: Toy Story 2++ (should be Toy Story ++2, actually. –Dan)
@pageman: The preg_replace ment Killers
@rattis: hackers on a plane (come one, someone had to do it). (HOAP, is a real thing).
@RySub: Puss in boot sector
@someara: @dakami Oh Backup Where Art Thou
@theharmonyguy: @dakami XSS in the City, with sequel XSS in the City: alert(2)
@ThemsonMester: Oceans 802.11
@Twirrim: 12 Angry Sysadmins
@redtwitdown: @Twirrim Saving Private Ryan [XX...................] 5.7% 16h47m remaining.
@0x17h: Twelve Code Monkeys
@davehull: APT Pupil
@Mackaber: The Angry Birds
@spridel11: $ whoami Legend
@Pickering: The King’s Speech Recognition Software
@BrightApollo: Saving Private Keys
@fkorling: Apocalype System.currentTimeMillis()
@OhAxi: Teenage Mutant Logo Turtles
@andreasudo: Planet of the APIs
@Ryallcowling: #00FF00 Lantern
@Pickering: The FIOS Connection
@andreasudo: Citizen DANE
@courtneyBolton: Gone with the Meme
@danvesma: Sense and adSensibility
@fkorling: In Her Majesty’s SQL Server
@ThemsonMester: To Kill an AWKing Bird books to movie…
@eikonoklastic: I Know What You Did Last Summer of Code
@mfukar: Port Knocked Up
@mfukar: Fantastic ARCFOUR
@ennor: Top GNU
@SecurityHumor: Two Macs One CUPS
@Madrox: Harry Potter and the Order Of Operations
@hmier: The Manchurian release candidate
@rogueclown: Kernighan and Ritchie do America
@alanpdx: Death Race Condition 2000
@hmier: A beautiful BIND
@Tylos: The Ring 0
@Tylos: ulimitless
@0x17h: The Hunchback of Notre DOM
@afabmedia: Information Technology Came from Outer Space
@Voulnet: BackTrack Mountain
@scottymuse: Sopadish
@davidgropper: The Girl With The Snapdragon Tattoo (cc: @0x17h)
@liambeeton: Independence 0day
@johngineer: 2 Fast 2 Fourier
@l0qii: elements[4]
@Slanderous23: Beauty and the BSD
@dakami: The A* Team (h/t @GKokoris)
@GKokoris: Jurassic PARC
@drb0n3z: James and the Giant Peach Fuzzer
@Mackaber: Indiana Jones and the Last Cross-site scripting
@artisan002: DIMM and DIMMer
@yawnbox: Stateless in Seattle
@addelindh: Low Orbit Ion Canonball Run
@buckstwits: Sudo The Right Thing
@ma1: A Phisher Called from Rwanda
@speno: Enemy Minecraft
@Rzieher: Sheldon Island
@Rzieher: The Men Who Stare at Goatse
@damphi: The good, the bad and the code you inherited from your predecessor
@damphi: Python on a plane
@agnat: 007 – License to … read, write and execute
@b4seb4nd: A League of Their Chown
@damphi: Deep Packet Inspector Gadget
@damphi: RoboCopy
@hvcco: Terminate and stay resident evil
@Nightwolf42: rm -rf / now
@0x17h: How to Train Your Dragon NaturallySpeaking
@FnordZilla: The Breakpoint Club
@0x17h: Paypal It Forward
@bocki_nbg: monty.py
@ArchangelAmael: Guess Who’s coming to Audit
@aymro: Google Intentions 2.0
@alech: When Alice Met Bob.
@stronate: We Need to Talk About Kelvin
@ArchangelAmael: The Birth of an Exploit
@meznak: vi for vendetta
@j4rkiLL: Alien vs. Administrator
@ArchangelAmael: The Grapes of $PATH
@artisan002: Two and a Half Men in the Middle
@angbor3D: Wall-E The Garbagecollector
@SeveQ: The Hills have iPhones
@ThemsonMester: Zack and Miri Configure, Make, Make Install a Porno
@artisan002: Dirty Twisted Pair
@swiftruss: Cowboys and Alienware
@mechtroid: Crank IPv4: Chev must surf the internet constantly. If he doesn’t find something funny every minute, he goes into cardiac arrest.
@eikonoklastic: How Stella Got Her Algorithm Back
@Nightwolf42: It’s a wonderful runtime
@KlaasJohansen: The Big Kernel Lock Theory #ReplaceFilmTitlesWithKernel
@Megaglest: Four web browsers and an Internet
@j0sema: LDAP Confidential
@FnordZilla: Clock Generator Orange
@TeethGrind3r: Crouching Tigerteam, Hidden Night Dragon
@_7and6_: “We can’t stop here, this is bash-country!” – Fear and Loathing in /usr/bin #nerdflix
@TeethGrind3r: Citizen Cain & Abel
@damphi: Dick Tracert
@_7and6_: Sex, Lies and Avi-Files
@yooogan: Watchdogmen
@stevelord: No country for old code
@_c_v_e_n: The Seven Layer Itch
@0x17h: Annie Hall-effect sensor
@apilosov: Da Vixie Code
@ArchangelAmael: The Magnificent Seven; layers of the OSI model
@xomexx: One overflow the cuckoo’s nest
@krizzzn: SELECT American FROM London WHERE wolf = 1
@GoddamnGeek: @dakami EIP Man
@0x17h: Malcolm X11
@imlxgr: The Bucket Sort
@ArchangelAmael: Who >brd< Roger Rabbit
@Meihrenfacht: @wlet @BeerweasleDev Lost in compilation ROFL
@ex1up: momopeche: Weekend At Bernoulli’s
@SubwayDealer: SHA Wars
@Voulnet: Batman BEGINS; DECLARES;
@Voulnet: netcat in the Hat
@fmiffal: grep -c “Monte Cristo”
@ira_victor: Monty Python and The Advanced Persistent Grail
@HamdanD: Sharepoint must die
@mrdaiber: wget -shorty / i See Deadpeople / wag the .doc / ctrl-s ‘lastdance.txt’
@HeshamAboElMagd: Pulp Function
@EmadMokhtar: RT @Voulnet: this.IsSparta();
@Ahmad_Hadeed: The Matrix[][]
@juphoff: Tim Cook, the Thief, His Wife & Her Lover.
@Voulnet: VBScript She Wrote
@old_man_mose: Indiana Jones and the Mountain of Dew
@Ibrahimism: How I hacked your mother
@f70r1: Grave of the Firefoxes
@otac0nFluX: the /x41 team
@mrdaiber: Alice in WLANd
@jochenWolters: Family GUI
@saschaleib: 0×20, the final frontier #NotAMovieTitle
@MagnusRevang: Enemy of the Statemachine
@f70r1: American History XML – an experienced coder wants to prevent his young colleague from taking the same wrong path that he did.
@cmhscout: Rear Windows 3.1
@imlxgr: 2038
@yeahyeahyens: dude, where’s my cdr?
@deepsec: Game of Inodes.
@lnxkid: The XORcist
@f70r1: The Old Man and the C
@webtonull: Ah, forgot “NoSQL for old men”
@mrngm: gcc -Wall -E
@mrdaiber: my big fat32 Greek wedding
@mrdaiber: revenge of the sithadmin
@kinesias: Mozilla (by Roland Emmerich)
@bluehavana: Sk!diocracy
@Politik2_0: 9 1/2 leaks
@SwieSchnubb: The Hurt Logger
@brx0: I dream of JNI
@mbeison: Murder on the Object Orient Express
@robotviki: Das BOOTP
@0xerror: How I Met Your Motherboard
[redacted]: Break Point
@Bashar3A: She’s Out Of My Scope
@JarrarM: AJAX Shrugged
@brx0: Spongebob O(N^2)Pants

Categories: lulz

February 17, 2012 Dan Kaminsky 6 comments

There’s been a lot of talk about this supposed vulnerability in RSA, independently discovered by Arjen Lenstra and James P. Hughes et al, and Nadia Heninger et al. I wrote about the bug a few days ago, but that was before Heninger posted her data. Lets talk about what’s one of the more interesting, if misunderstood, bugs in quite some time.

---

SUMMARY
INTRODUCTION
THE ATTACK
IT’S NOT ABOUT RON AND WHIT
WHO MATTERS
FAILURE TO ENROLL
THE ACTUAL THREAT
ACTIONABLE INTELLIGENCE
CONCLUSION

---

SUMMARY

• The “weak RSA moduli” bug is almost (and possibly) exclusively found within certificates that were already insecure (i.e. expired, or not signed by a valid CA).
• This attack almost certainly affects not a single production website.
• The attack utilizes a property of RSA whereby if half the private key material is shared between two public keys, the private key is leaked. Researchers scaled this method to cross-compare every RSA key on the Internet against every other RSA key on the Internet.
• The flaw has nothing to do with RSA or “multi-secret” systems. The exact same broken random number generator would play just as much havoc, if not more, with “single-secret” algorithms such as ECDSA.
• DSA, unlike RSA, leaks the private key with every signature under conditions of faulty entropy. That is arguably worse than RSA which leaks its private key only during generation, only if a similar device emits the same key, and only if the attacker finds both devices’ keys.
• The first major finding is that most devices offer no crypto at all, and even when they do, the crypto is easily man-in-the-middled due to a presumption that nobody cares whether the right public key is in use.
• Cost and deployment difficulty drive the non-deployment of cryptographic keys even while almost all systems acquire enough configuration for basic connectivity.
• DNSSEC will dramatically reduce this cost, but can do nothing if devices themselves are generating poor key material and expecting DNSSEC to publish it.
• The second major finding is that it is very likely that these findings are only the low hanging fruit of easily discoverable bad random number generation flaws in devices. It is specifically unlikely that only a third of one particular product had bad keys, and the rest managed to call quality entropy.
• This is a particularly nice attack in that no knowledge of the underlying hardware or software architecture is required to extract the lost key material.
• Recommendations:
  1. Don’t panic about websites. This has very little to absolutely nothing to do with them.
  2. When possible and justifiable, generate private key material outside your embedded devices, and push the keys into them. Have their surrouding certificates signed, if feasible.
  3. Audit smartcard keys.
  4. Stop buying or building CPUs without hardware random number generators.
  5. Revisit truerand, an entropy source that only requires two desynchronized clocks, possibly integrating it into OpenSSL and libc.
  6. When doing global sweeps of the net, be sure to validate that a specific population is affected by your attack before including it in the vulnerability set.
  7. Start seriously looking into DNSSEC. You are deploying a tremendous number of systems that nobody can authenticate.

---

INTRODUCTION
If there’s one thing to take away from this entire post, it’s the following line from Nadia Heninger’s writeup:

Only one of the factorable SSL keys was signed by a trusted certificate authority and it has already expired.

What this means, in a nutshell, is that there was never any security to be lost from crackable RSA keys; due to failures in key management, almost certainly all of the affected keys were vulnerable to being silently “swapped out” by a Man-In-The-Middle attacker. It isn’t merely the fact that all the headlines proclaiming “0.2% of websites using RSA are insecure” are straight up false, because the flaws are concentrated on devices. It’s also the case that the devices themselves were already using RSA insecurely to begin with, merely by being deployed outside a key management system.

If there’s a second thing to take away, it’s that this is important research with real actions that should be taken by the security community in response. There’s no question this research is pointing to things that are very wrong with the systems we depend on. Do not make the mistake of discounting this work as merely academic. We have a problem with random numbers, that is even larger than Lenstra and Hughes and Heninger are finding with their particular mechanism.

---

THE ATTACK

To grossly simplify, RSA works by:

1) Generating two random primes, p and q. These are private.
2) Multiplying p ad q together into n. This becomes public, because figuring out the exact primes used to create n is Hard.
3) Content is signed or decrypted with p and q.
4) Content is verified or encrypted with n.

It’s obvious that if p is not random, q can be calculated: n/p==q, because p*q==n. What’s slightly less obvious, however, is that if either p or q is repeated across multiple n’s, then the repeated value can be trivially extracted using an ancient algorithm by Euclid called the Greatest Common Denominator test. The trick looks something like this (you can follow along with Python, if you like):

>>> from gmpy import *
>>> p=next_prime(rand(“next”))
>>> q=next_prime(rand(“next”))
>>> p
mpz(136093819)
>>> q
mpz(118190411)
>>> n=p*q
>>> n
mpz(16084984402169609)

Now we have two primes, multiplied into some larger n.

>>> q2=next_prime(rand(“next”))
>>> n2=p*q2
>>> n2
mpz(289757928023349293)

Ah, now we have n2, which is the combination of a previously used p, and a newly generated q2. But look what an attacker with n and n2 can do:

>>> gcd(n,n2)
mpz(136093819)
>>> p
mpz(136093819)

Ta-da! p falls right out, and thus q as well (since again, n/p==q). So what these teams did was gcd every RSA key on the Internet, against every other RSA key on the Internet. This would of course be quite slow — six million keys times six million keys is thirty six trillion comparisons — and so they used a clever algorithm to scale the attack such that multiple keys could be simultaneously compared against one another. It’s not clear what Lenstra and Hughes used, but Heninger’s implementation leveraged some 2005 research from (who else?) Dan Bernstein.

That is the math. What is the impact, upon computer security? What is the actionable intelligence we can derive from these findings?

Uncertified public keys or not, there’s a lot to worry about here. But it’s not at all where Lenstra and Hughes think.

---

IT’S NOT ABOUT RON AND WHIT

Lenstra and Hughes, in arguing that “Ron was Wrong, Whit was right”, declare:

Our conclusion is that the validity of the assumption is questionable and that generating keys in the real world for “multiple-secrets” cryptosystems such as RSA is signicantly riskier than for “single-secret” ones such as ElGamal or (EC)DSA which are based on Die-Hellman.

The argument is essentially that, had those 12,000 keys been ECDSA instead of RSA, then they would have been secure. In my previous post on this subject (a post RSA Inc. itself is linking to!) I argued that this paper, while chock-full of useful and important data, failed to make the case that the blame could be laid at the feet of the “multiple-secret” RSA. Specifically:

• Risk in cryptography is utterly dominated, not by cipher selection, but by key management. It does not matter the strength of your public key if nobody knows to demand it. Whatever the differential risk is that is introduced by the choice of RSA vs. ECDSA pales in comparison to whether there’s any reason to believe the public key in question is the actual key of the desired target. (As it turns out, few if any of the keys with broken moduli, had any reason to trust them in the first place.)
• There aren’t enough samples of DSA in the same kind of deployments to compare failure rates from one asymmetric cipher to another.
• If one is going to blame a cipher for implementation failures in the field, it’s hard to blame the maybe dozens of implementations of RSA that caused 12,000 failures, while ignoring the one implementation of ECDSA that broke millions upon millions of Playstation 3′s.

But it wasn’t until I read the (thoroughly excellent) blog post from Heninger that it became clear that, no, there’s no rational way this bug can be blamed on multi-secret systems in general or RSA in particular.

However, some implementations add additional randomness between generating the primes p and q, with the intention of increasing security:

prng.seed(seed)
p = prng.generate_random_prime()
prng.add_randomness(bits)
q = prng.generate_random_prime()
N = p*q

If the initial seed to the pseudorandom number generator is generated with low entropy, this could result in multiple devices generating different moduli which share the prime factor p and have different second factors q. Then both moduli can be easily factored by computing their GCD: p = gcd(N1, N2).

OpenSSL’s RSA key generation functions this way: each time random bits are produced from the entropy pool to generate the primes p and q, the current time in seconds is added to the entropy pool. Many, but not all, of the vulnerable keys were generated by OpenSSL and OpenSSH, which calls OpenSSL’s RSA key generation code.

Would the above code become secure, if the asymmetric cipher selected was the single-secret ECDSA instead of the multi-secret RSA?

prng.seed(seed);
ecdsa_private_key=prng.generate_random_integer();

No. All public keys emitted would be identical (as identical as they’d be with RSA, anyway). I suppose it’s possible we could see the following construction instead:

prng.seed(seed);
first_half=prng.generate_random_integer();
prng.add_randomness(bits);
second_half=prng.generate_random_integer();
ecdsa_private_key=concatenate(first_half, second_half);

…but I don’t think anyone would claim that ECDSA, DSA, or ElGamel is secure in the circumstance where half its key material has leaked. (Personal note: Prodded by Heninger, I’ve personally cracked a variant of RSA-1024 where all bits set to 1 were revealed. It wasn’t difficult — cryptosystems fail quickly when their fundamental assumptions are violated.)

Hughes has made the argument that RSA is unique here because the actions of someone else — publishing n composed of your p and his q — impact an innocent you. Alas, you’re no more innocent than he is; you’re republishing his p, and exposing his q2 as much as he’s exposing your q. Not to mention, in DSA, unlike RSA, you don’t need someone else’s help to expose your private key. A single signature, emitted without a strong RNG, is sufficient. As we saw from the last major RNG flaw, involving Debian:

Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation.

The fact that Lenstra and Hughes found a different vulnerability rate for DSA keys than RSA keys comes from the radically different generator for the former — PGP keys as generated by GNU Privacy Guard or PGP itself. This is not a thing commonly executed on embedded hardware.

There is a case to be made for the superiority of ECDSA over RSA. Certainly this is the conclusion of various government entities. I don’t think anyone would be surprised if the latter was broken before the former. But this situation, this particular flaw, reflects nothing about any particular asymmetric cipher. Under conditions of broken random number generation, all ciphers are suspect.

Can we dismiss these findings entirely, then?

Lets talk about that.

---

WHO MATTERS

The headlines have indeed been grating. “Only 99.8% of the worlds PKI uses secure randomness”, said TechSnap. “EFF: Tens of thousands of websites’ SSL “offers effectively no security” from Boing Boing. And, of course, from the New York Times:

The operators of large Web sites will need to make changes to ensure the security of their systems, the researchers said.

The potential danger of the flaw is that even though the number of users affected by the flaw may be small, confidence in the security of Web transactions is reduced, the authors said.
…
“Some people may say that 99.8 percent security is fine,” he added. That still means that approximately as many as two out of every thousand keys would not be secure.

The operators of large web sites will not need to make any changes, as they are excluded from the population that is vulnerable to this flaw. It is not two out of every thousand keys that is insecure. Out of those keys that had any hope of being secure to begin with — those keys that participate in the (flawed, but bear with me) Certificate Authority system — approximately none of these keys are threatened by this attack.

It is not two out of every 1000 already insecure keys that are insecure. It is 1000 of 1000. But that is not changed by the existence of broken RSA moduli.

To be clear, these numbers do not come from Lenstra and Hughes, who have cautiously refused to disclose the population of certificates, nor from the EFF, who have apparently removed those particular certificates from the SSL Observatory (interesting side project: Diff against the local copy). They come from Heninger’s research, which not only discloses who isn’t affected (“Don’t worry, the key for your bank’s web site is probably safe”), but analyzes the population that is:

Firewall product X:
52,055 hosts in our SSL dataset
6,730 share public keys
12,880 have factorable keys

Consumer-grade router Y:
26,952 hosts in our SSL dataset
9,345 share public keys
4,792 have factorable keys

Enterprise remote access solution Z:
1,648 hosts in our SSL dataset
24 share public keys
0 factorable

Finally, we get to why this research matters, and what actions should be taken in response to it. Why are large numbers of devices — of security devices, even! — not even pretending to successfully manage keys? And worse, why are the keys they do generate (even if nobody checks them) so insecure?

---

FAILURE TO ENROLL

Practically every device on a network is issued an IP address. Most of them also receive DNS names. Sometimes assignment is dynamic via DHCP, and sometimes (particularly on corporate/professionally managed networks) addressing is managed statically through various solutions, but basic addressing and connectivity across devices from multiple vendors is something of a solved problem.

Basic key management, by contrast, is a disaster.

You don’t have to like the Certificate Authority system. I certainly don’t; while I respect the companies involved, they’re pretty clearly working with a flawed technology. (I’ve been talking about this since 2009, see the slides here. Slide 22 talks about the very intermediate certificate issuance that people are now worrying about with respect to Trustwave and GeoTrust) However…

Out of hundreds of millions of servers on the Internet with globally routable IP addresses, only about six million present public keys to be authenticated against. And of those with keys, only a relatively small portion — maybe a million? — are actually enrolled into the global PKI managed by the Certificate Authorities.

The point is not that the CA’s don’t work. The point is that, for the most part, clients don’t care, nothing is checking the validity of device certificates in the first place. Most devices, even security devices, are popping these huge errors every time the user connects to their SSL ports. Because this is legitimate behavior — becaus