This is an incomplete discussion of SSL/TLS authentication and encryption. This post only goes into RSA and does not discuss DHE, PFS, elliptical, or other mechanisms.
In a previous post I created an 15,360-bit RSA key and timed how long it took to create the key. Some may have thought that was some sort of stunt to check processor speed. I mean, who needs an RSA key of such strength? Well, it turns out that if you actually need 256 bits of security then you’ll actually need an RSA key of this size.
According to NIST (SP 800-57, Part 1, Rev 3), to achieve 256 bits of security you need an RSA key of at least 15,360 bits to protect the symmetric 256-bit cipher that’s being used to secure the communications (SSL/TLS). So what does the new industry-standard RSA key size of 2048 bits buy you? According to the same document that 2048-bit key buys you 112 bits of security. Increasing the bit strength to 3072 will bring you up to the 128 bits that most people expect to be the minimum protection. And this is assuming that the certificate and the certificate chain are all signed using a SHA-2 algorithm (SHA-1 only gets you 80 bits of security when used for digital signatures and hashes).
So what does this mean for those websites running AES-256 or CAMELLIA-256 ciphers? They are likely wasting processor cycles and not adding to the overall security of the circuit. I’ll make two examples of TLS implementations in the wild.
First, we’ll look at wordpress.com. This website is protected using a 2048-bit RSA certificate, signed using SHA256, and using AES-128 cipher. This represents 112 bits of security because of the limitation of the 2048-bit key. The certificate is properly chained back to the GoDaddy CA which has a root and intermediate certificates that are all 2048 bits and signed using SHA-256. Even though there is a reduced security when using the 2048-bit key, it’s likely more efficient to use the AES-128 cipher than any other due to chip accelerations that are typically found in computers now days.
Next we’ll look at one of my domains: christensenplace.us. This website is protected using a 2048-bit RSA certifcate, signed using SHA-1, and using CAMELLIA-256 cipher. This represents 80 bits of security due to the limitation of the SHA-1 signature used on the certificate and the CA and intermediate certificates from AddTrust and COMODO CA. My hosting company uses both the RC4 cipher and the CAMELLIA-256 cipher. In this case the CAMELLIA-256 cipher is a waste of processor since the certificates used aren’t nearly strong enough to support such encryption. I block RC4 in my browser as RC4 is no longer recommended to protect anything. I’m not really sure exactly how much security you’ll get from using RC4 but I suspect it’s less than SHA-1.
So what to do? Well, if system administrators are concerned with performance then using a 128-bit cipher (like AES-128) is a good idea. For those that are concerned with security, using a 3072-bit RSA key (at a minimum) will give you 128 bits of security. If you feel you need more bits of security than 128 then generating a solid, large RSA key is the first step. Deciding how many bits of security you need all depends on how long you want the information to be secure. But that’s a post for another day.
$ time openssl genrsa 15360
Generating RSA private key, 15360 bit long modulus
After years of using caff for my PGP key-signing needs I finally come across the answer to a question I’ve had since the beginning. I document it here so that I may keep my sanity next time I go searching for the information.
My question was “how do you make a specific certification in a signature?”. As defined in RFC 1991, section 6.2.1, the four types of certifications are:
<10> - public key packet and user ID packet, generic certification ("I think this key was created by this user, but I won't say how sure I am") <11> - public key packet and user ID packet, persona certification ("This key was created by someone who has told me that he is this user") (#) <12> - public key packet and user ID packet, casual certification ("This key was created by someone who I believe, after casual verification, to be this user") (#) <13> - public key packet and user ID packet, positive certification ("This key was created by someone who I believe, after heavy-duty identification such as picture ID, to be this user") (#)
Generally speaking, the default settings in caff only provide the first level “generic” certification. Tonight I found information specific to ~/.caff/gnupghome/gpg.conf. This file can contain, as far as I know, can contain three lines:
I can’t find any official information on this file as the man pages are a little slim on details. That said, if you use caff you should definitely create this file and populate it with the above at a minimum with the exception of the default-cert-level. The default-cert-level should be whatever you feel comfortable setting this as. My default is “2″ for key signing parties (after I’ve inspected an “official” identification card and/or passport). The other two settings are important as they provide assurances of using a decent SHA-2 hash instead of the default
It’s good to get a team together, face-to-face, that usually only meets virtually via IRC on occasion. The Fedora Docs Project team recently had such an opportunity when they met in the Red Hat offices in Raleigh and Brno. Linked by a video teleconference, the two groups converged to discuss new work-flows for Publican 4, hacking on some guides, discussing management issues, and working to get the new Docs website built and configured. Here are some of the highlights of the event:
Work-flow update for Publican 4
The release of Fedora 20 also saw the release of Publican 4. Publican 4 isn’t quite backwards compatible with the Publican 2 we were using so an update to our work-flow was necessary. We’ve also made it to a point in our work where using the old web.git repo for publishing just isn’t working any longer. The new way of publishing involves using Koji to build our documents in RPMs and place them safely into a repository where they can be grabbed by our backend server and be published to the world. This change not only represents new commands but also a different mindset to publishing. The new procedures were documented and tested so we’ll be able to start utilizing these as soon as our backend server gets fixed.
Guides hacked upon
You know those guides that seem to languish? Yeah, I’ve got a few of those. I did spend some time working on a few guides that will hopefully go live for Fedora 20 or 21.
The Accessibility Guide has really taken a backseat in recent releases. I’m not sure much has changed for many users but it’s good to keep the document current for any new users that may require a little assistance in making their computer work for them. I was able to take a lot of stuff out of the guide, mostly GNOME packages that are no longer in Fedora and add a couple of packages I found for KDE. I’m hoping I can do a better review of what’s available in Fedora before Fedora 21 comes around.
Amateur Radio Guide
I finally got around to adding CQRLOG to the guide. I really love CQRLOG as a logging program so I’m happy to share some of that information with other amateur radio operators that come to Fedora looking for a FOSS solution for their radio activities. John made a few additions as well so I suspect the next release will have some added goodness that people should find helpful.
This is where I spent most of my time working. The style guide was moved from the wiki into the guide and other useful information was added as well.
This guide has never really seen the light of day. This is due to the fact that translations of this guide would be nearly useless as they wouldn’t be in any particular order. Publican 4 fixes this long-standing bug and so I, once again, have hope to publish this book.
Yeah, there’s always some hacking on the security guide when I’m around. This time there was some testing of the new Yubikey Neo and getting them to do tricks inside Fedora.
New backend server
Videos of the FAD
Back in December I met with Eric Gundersen (@ericg), CEO of Mapbox, and Alex Barth (@lxbarth), lead of Mapbox’s Data Team, at their DC office to discuss their work within the open source community. I was happy to find their office have the “start up” feel to them and everyone seems to be very passionate about their work. I’ve since run into a few Mapbox employees that, even outside the office, seem to have maps in their hearts. I suspect this company will provide even more FOSS goodness in the future and will be one to watch.
If you haven’t read the story it can be found on the OpenSource.com website.
Just two short weeks after the release of the previous version of CQRLOG, version 1.7.1 has been released to the public with the following bugfixes:
- “When TRX control is not active, use frequency and mode from NewQSO window” option to Preferences->Band map added
- CTRL+N hotkey to QSO list window added (do NOT send QSL)
- TRX control window was not sizeable – fixed
- when ESC was pressed twice in Remote mode, log crashed – fixed
- program crashed when freq was entered with comma as decimal separator – fixed
- broken grid square statistic fixed
If you can, please evaluate this new package and provide karma. The new package should already be in rawhide.
I recently upgrade to Fedora 20 and quickly found my offlineimap instance failing. I was getting all kinds of errors regarding the certificate not being authenticated. Concerned wasn’t really the word I’d use to describe my feelings around the subject. Turns out, the version of offlineimap in Fedora 20 (I won’t speculate as to earlier versions) requires a certificate fingerprint validation or a CA validation if
SSL=yes is in the configuration file (.offlineimaprc). I was able to remedy the situation by putting
sslcacertfile = /etc/ssl/certs/ca-bundle.crt in the config file.
I won’t speculate as to the functionality in earlier versions but checking to make sure the SSL certificate is valid is quite important (MITM). If you run across a similar problem just follow the instructions above and all should, once again, be right with the world.