Josh Wieder

Recently I have started coming across somewhat unusual entries in the access and error logs for a few of the Apache web servers that I am responsible for maintaining. The entries look like this: 95.156.251.10 - - [03/Nov/2015:13:56:23 -0500] "\x16\x03\x02\x01o\x01" 400 226 "-" "-" Here is another example: 184.105.139.68 - - [03/Nov/2015:23:48:54 -0500] "\x16\x03\x01" 400 226 "-" "-" These errors will be generated on a website configured to use SSL - and in fact, error messages similar to these can be generated by misconfiguring SSL for your website. This error message, for instance, can indicate an attempt to access Apache through SSL while the OpenSSL engine is either disabled or misconfigured: Invalid method in request \x80g\x01\x03 Connections that generate that error would not be successful. This post, however, assumes that your website is working normally when used normally. So what gives? The error indicates

Some time ago I wrote a post about the dismaying history of US government attempts to regulate encryption out of existence . I had to omit quite a bit; it was a post and not a book after all. One of the details left out of the story was the DHE_EXPORT cipher suites. During the 90's, developers were forced by the US government to us deliberately insecure ciphers when communicating with entities in foreign countries (readers will remember from the last post that law makers were convinced that encryption should fall under the same rules as weapons technology, and thus could not be shared with anyone outside the Father Land). These insecure ciphers became DHE_EXPORT. The DH stands for Diffie-Hellman; the key exchange system that bears their name was first published in 1976. Along with the cipher suite was a mechanism to force a normal encrypted transaction to downshift to a lower-bit DHE_EXPORT cipher. As so many short-sighted technology regulations have done in the past, this silly

Amazon S3 subscribers recently received a form letter like this one: Dear AWS Customer, This message explains some security improvements in our services. Your security is important to us. Please review the entire message carefully to determine whether your use of the services will be affected, and if so what you need to do. As of 12:00 AM PDT May 20, 2015, AWS will discontinue support of SSLv3 for securing connections to S3 buckets. Security research published late last year demonstrated that SSLv3 contained weaknesses in its ability to protect and secure communications. These weaknesses have been addressed in Transport Layer Security (TLS), which is the replacement for SSL. Consistent with our top priority to protect AWS customers, AWS will only support versions of the more modern TLS rather than SSLv3. You are receiving this email because some of your users are accessing Amazon S3 using a browser configured to use SSLv3, or some of your existing applications that use Amazon S3 a

For many years in the IT community, it was assumed that time spent travelling on an airplane was wasted. At best, you could make do with expensive and often-unreliable cell network coverage for connectivity. Even that was an issue, though, because of the airline's histrionic and decades-out-of-date concern that electronic devices interfered with flight navigation equipment. On top of having to pay a premium for unreliable service, you had to be sneaky about it, as well. Some of us handled the situation better than others So when in-flight internet services first started to become integrated to major airline fleets en masse, many tech people applauded. Those of us who had to attend trade shows, travel to meet customers or were responsible for multiple data center locations could get things done as we bounced back and forth across the country.  The bandwidth was every bit as expensive as roaming cell network charges, regularly more expensive, but the planes were being equipped

The Details This is a bit of an old story, but I've found to my unpleasant surprise that the issues surrounding the story are not widely understood or known. Here's the gist: leaks from the US intelligence service have explicilty confirmed that the NSA targets systems administrators that have no ties to terrorism or extremist politics . If you are responsible for building and maintaining networks, the NSA will place you under surveillance both personally or professionally; they will hack your email, social network accounts and cell phone. The thinking behind this alarming strategy is that compromising a sysadmin provides root-level access to systems that enable further surveillance; hack an extremist's computer, and you track just that extremist. Hack a sysadmin's computer, and you can track thousands of users who may include extremists among them (its a strategy that is remarkably similar to the targeting of doctors in war zones ). Five years ago such a lead paragr

I received a notification from a large security auditing firm that of the ciphers currently available, only RC4 ciphers will be considered PCI compliant. My assumption based on the notification is that this move is intended as a rejection of CBC (Cipher Block Chaining). Well, that's fine as far as I am concerned. CBC has some serious issues as implemented in SSL v3 / TLS v1.0. In a nutshell, you can time responses for applications using the block cipher to get ranges of possible data in SSLv3 and partial payload decryption in TLS. So-called "stream" ciphers like RC4 are immune to this particular attack vector. You don't get private keys from the attack, its by no means a fast attack (minimum of three hours), and you need access to monitor the session . Further, patches for CBC exist to over-ride the timing exploit (for example the NSS libraries used by Mozilla have been patched). I will save debunking the man in the middle hysteria for a later post. What frustrate

I saw a lot of misinformation about this on the inter-tubes recently, some of it intentional misleading of customers, some of it unintentional, so it might be remedial for a lot of readers but posting a clarification here because its worth it to help clear up the confusion. Here are some facts that should help people when first making the leap to securing multiple server environments: Servers are domain and private key specific. They are not machine specific. You are welcome to generate multiple SSL certificates for the same domain to host on separate servers. Think for a bit, this *has* to be true. When everyone goes to https://google.com, are they hitting the same web server or SSL caching server? Of course not.* The most common scenario where this would be valuable is with a load balanced web cluster, but I recently came across this in a deployment with web and mail component where the mail admin neglected to give their MTA a unique FQDN *and* the organization is using SSL/TLS f