Archive for the ‘Confidentiality’ Category

RC4 prohibited

2015-02-19 Leave a comment

Originally posted on securitypitfalls:

After nearly half a year of work, the Internet Engineering Task Force (IETF) Request for Comments (RFC) 7465 is published.

What it does in a nutshell is disallows use of any kind of RC4 ciphersuites. In effect making all servers or clients that use it non standard compliant.

View original

Categories: Confidentiality, Encryption Tags: , ,

Securing Secure Shell

2015-01-06 2 comments

I was passed an interesting article, this morning, regarding hardening secure shell (SSH) against poor crypto that can be a victim of cracking by the NSA and other entities.  The article is well written and discusses why the changes are necessary in light of recent Snowden file releases.

How to really screw up TLS

2014-12-12 1 comment

I’ve noticed a few of my favorite websites failing with some odd error from Firefox.

Firefox's Unable to connect securely error messageThe Firefox error message is a bit misleading.  It actually has nothing to do with the website supporting SSL 3.0 but the advanced info is spot on.  The error “ssl_error_no_cypher_overlap” means that the client didn’t offer any ciphers that the server also supports.  Generally when I see this I assume that the server has been setup poorly and only supports unsafe ciphers.  In this case the website only supports the RC4 cipher.  I wondered why I was starting to see a reversal of removing RC4 from so many websites recently (especially since RC4 is very weak and is on the way out).  Apparently these websites all use the F5 load balancer that had a bad implementation of the TLS 1.0 standard causing a POODLE-like vulnerability.

Stepping back for a moment, back in October the POODLE vulnerability hit the streets and a mass exodus from SSL 3.0 happened around the world.  I was happy to see so many people running away from the broken cryptographic protocol and very happy to see the big push to implementing the latest version of TLS, TLS 1.2.  So with SSL 3.0 out of the way and the POODLE vulnerability being squelched why are we seeing problems in TLS 1.0 now?

Well, simply put, F5 load balancers don’t implement TLS 1.0 correctly.  The problem with SSL 3.0 is that the padding format isn’t checked.  Apparently in the F5 devices it’s still a problem in TLS 1.0.  And while the company did offer up patches to fix the issue, some really bad advice has been circulating the Internetz telling people to only support RC4, again.  Sigh.

When RC4 finally dies a fiery death I’ll likely throw a party.  I’m sure I won’t be the only one…

Categories: Confidentiality, Encryption, Security Tags: , ,

Automated configuration analysis for Mozilla’s TLS guidelines

2014-10-09 Leave a comment

My friend Hubert has been doing a lot of work to make better the world a little safer.  Glad he’s getting some recognition.  Here’s a great article on testing your server for proper SSL/TLS configurations.

Generating a PGP key using GnuPG

2014-06-16 3 comments

Generating a PGP using GnuPG (GPG) is quite simple.  The following shows my recommendations for generating a PGP key today.

$ gpg --gen-key 
gpg (GnuPG) 1.4.16; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
 (1) RSA and RSA (default)
 (2) DSA and Elgamal
 (3) DSA (sign only)
 (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 3072
Requested keysize is 3072 bits
Please specify how long the key should be valid.
 0 = key does not expire
  = key expires in n days
 w = key expires in n weeks
 m = key expires in n months
 y = key expires in n years
Key is valid for? (0) 1y
Key expires at Tue 16 Jun 2015 10:32:06 AM EDT
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
 "Heinrich Heine (Der Dichter) <>"
Real name: Given Surname
Email address:
Comment: Example
You selected this USER-ID:
 "Given Surname (Example) <>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key 2CFA0010 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 2 signed: 49 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: depth: 1 valid: 49 signed: 60 trust: 48-, 0q, 0n, 0m, 1f, 0u
gpg: depth: 2 valid: 8 signed: 17 trust: 8-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2014-09-09
pub 3072R/2CFA0010 2014-06-16 [expires: 2015-06-16]
 Key fingerprint = F81D 16F8 3750 307C D090 4DC1 4D05 E6EF 2CFA 0010
uid Given Surname (Example) <>
sub 3072R/48083419 2014-06-16 [expires: 2015-06-16]

The above shows the complete exchange between GPG and myself.  I’ll point out a couple of selections I made and explain why I made those choices.

Key type selection

I selected the default selection of two RSA keys.  The keys used for signing and encryption will both be RSA which is strong right now.  DSA has been proven to be weak in certain instances and should be avoided in this context.  I have no comment on ElGamal as I’ve not done research here.  Ultimately the choice is up to you.

Bit strength

I’ve selected 3072 instead of the default 2048 here.  I recommend this as the minimum bit strength as this provides 128 bits of security as compared to 112 bits of security with 2048.  128 bits of security should be secure beyond 2031 as per NIST SP 800-57, Part 1, Rev 3.

Key expiration

By default, I make my keys expire after a year.  This is a fail-safe and can be later modified before the expiration to extend the expiration another year.  This makes sure the key will self destruct if you ever lose control of it.

Identifying information

You’ll  now be asked to add your name and email address.  This should be self-explanatory.

Key revocation

Once you have completed your key generation now is the time to generate the key revocation file.  If you ever lose control of your key you should immediately upload this file to the public key servers so everyone using your key will know that it has [potentially] been compromised.  Once you’ve generated this revocation just keep it somewhere safe.  You can even print it out and keep it locked up somewhere.  It’s important to do this this ahead of time as you may not be able to do this later.  You’ll obviously want to substitute your own keyid for 2CFA0010.

$ gpg --gen-revoke 2CFA0010
sec 3072R/2CFA0010 2014-06-16 Given Surname (Example) <>
Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
 0 = No reason specified
 1 = Key has been compromised
 2 = Key is superseded
 3 = Key is no longer used
 Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
Reason for revocation: Key has been compromised
(No description given)
Is this okay? (y/N) y
You need a passphrase to unlock the secret key for
user: "Given Surname (Example) <>"
3072-bit RSA key, ID 2CFA0010, created 2014-06-16
ASCII armored output forced.
Revocation certificate created.
Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable. But have some caution: The print system of
your machine might store the data and make it available to others!
Version: GnuPG v1
Comment: A revocation certificate should follow

Proper key storage

Generally speaking, your private PGP key is stored on your computer encrypted.  It is protected by your normal security measures of your computer and whatever password you set.  There is a better way.  Use a hardware security module (HSM) like a Yubikey Neo, OpenPGP card, or CryptoStick to protect  your private key from disclosure.

Publishing your public key

Now that you have your PGP keys you’ll want to publish your public key to the key servers so others can easily obtain it to validate your signatures.

$ gpg  --keyserver hkps:// --send-keys 2CFA0010

You’ll obviously want to substitute your own keyid for 2CFA0010.  This command will send your key to the SKS public key servers which will then replicate your key around the world in a few hours.


SSL/TLS Trends

2014-05-20 1 comment

My friend Hubert has started compiling statistics of Alexa’s top 1 million websites.  Specifically, he’s looking at their SSL/TLS settings and attempting to show trends in the world that is port 443.  He recently released his May numbers showing a slow but mostly improving security environment.  I’m hoping he’ll be able to chart these trends in a way to make it easier for people to consume the data and be able to dynamically look for data that they are interested in.  I guess we’ll have to wait and see what come about.  Until then I believe he’ll continue to post his monthly numbers on the Fedora Security List.

256 Bits of Security

2014-04-17 3 comments

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 60 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  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:  This website is protected using a 2048-bit RSA certifcate, signed using SHA-1, and using CAMELLIA-256 cipher.  This represents 80 60 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.


Get every new post delivered to your Inbox.

Join 226 other followers