I’ve been working on securing my postfix configuration to enforce certificate validation and encryption on some known, higher-volume, or more sensitive connections between SMTP servers (port 25).
On many of the connections I’ve setup for secure transport there have been no problems (assuming proper TLS certificates are used). Unfortunately Gmail™ has been a problem. Sometimes it verifies and validates the certificate and other times it doesn’t… for days.
After conferring with Google Security I believe I’ve come up with a solution. In my tls_policy file I’ve added the following:
gmail.com secure match=.google.com:google.com ciphers=high protocols=TLSv1.2
So far this is working
but I’ll continue to test.
If you run your own SMTP server and wish to maintain a secure connection with Gmail this is an easy way to enforce encryption as well as validate the certificate. Of course this doesn’t protect the message while it’s being stored on the server or workstation (or on Google’s internal network). To protect messages at rest (on a server) one should use GPG or S/MIME. Using both TLS over the network between servers and GPG or S/MIME is beneficial to provide protection of the messages going over the Internet.
This configuration is applicable with the OpenSSL version shipped with CentOS 6/RHEL 6. Implementing this on CentOS 7/RHEL7 or another flavor of Linux may require a different/better configuration.
The policy has been updated for CentOS 7/RHEL 7 which supports TLSv1.2 on Postfix. Other services can also be setup similarly:
google.com secure ciphers=high protocols=TLSv1.2 comcast.net secure ciphers=high protocols=TLSv1.2 verizon.net secure ciphers=high protocols=TLSv1.2 hotmail.com secure ciphers=high protocols=TLSv1.2
A thought that I haven’t had a chance to fully consider (so I’m asking the Internet to do that for me)…
I have a geographically-diverse team that uses GPG to provide integrity of their messages. Usually, a team like this would all huddle together and do a formal key-signing event. With several large bodies of water separating many of the team members, however, it’s unlikely that we could even make that work.
The alternative I thought of was using a video chat meeting to facilitate the face-to-face gathering and exchange of information. There are obviously some risks, here, but I wonder if those risks are suitably mitigated through the use of authenticated/encrypted links to the video chat system? Can anyone point to why this would be a bad idea?
SouthEast LinuxFest is happening this upcoming weekend. I offered to host a PGP (I’ll substitute PGP for GPG, GnuPG, and other iterations) keysigning and CACert Assertion event and have been scheduled for 6:30 PM in the Red Hat Ballroom. Since there is a little bit of planning needed on the part of the participant I’m writing this to help the event run smoothly.
Participating in the PGP Keysigning Event
If you haven’t already, generate your PGP keys. Setting up your particular mail client (MUA) is more than what I’ll discuss here but there is plenty of resources on the Internet. Send me (firstname.lastname@example.org – signed, preferably encrypted to 0x024BB3D1) the fingerprint of your PGP key no later than 3:00PM on Saturday afternoon. If you don’t send me your fingerprint by that time you’ll be responsible for providing it to everyone at the keysigning event on paper. Obtaining your key’s fingerprint can be done as follows:
$ gpg --fingerprint 024bb3d1 pub 4096R/024BB3D1 2011-08-11 [expires: 2015-01-01] Key fingerprint = 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 uid Eric Harlan Christensen <email@example.com> uid Eric "Sparks" Christensen <firstname.lastname@example.org> uid Eric "Sparks" Christensen <email@example.com> uid Eric "Sparks" Christensen <firstname.lastname@example.org> uid [jpeg image of size 2103] uid Eric Harlan Christensen <email@example.com> sub 3072R/DCA167D5 2013-02-03 [expires: 2023-02-01] sub 3072R/A9D8262F 2013-02-03 [expires: 2023-02-01] sub 3072R/56EA1030 2013-02-03 [expires: 2023-02-01]
Just send me the “Key fingerprint” portion and your primary UID (name and email address) and I’ll include it on everyone’s handout. You’ll need to bring your key fingerprint on paper for yourself to verify that what I’ve written on the paper is, indeed, correct.
At the event we’ll quickly do a read of all the key fingerprints and validate them as correct. Then we’ll line up and do the ID check. Be sure you bring a photo ID with you so that we can validate who you are with who you claim to be to the authorities. People are generally okay with a driver’s license; some prefer a passport. Ultimately it’s up to the individual what they will trust.
CACert is a free certificate authority that signs X509 certificates for use in servers, email clients, and code signing. If you are interested in using CACert you need to go sign up for an account before the event. Once you have established an account, login and select “US – WoT Form” from the CAP Forms on the right-side of the page. Print a few of these forms and bring them with you (I hope to have a final count of the number of assurers that will be available but you’ll need one form per assurer). You’ll need to present your ID to the assurer so they can verify who you are. They will then award you points in the CACert system.
If you have any questions about the event feel free to ask them here (using a comment) or email me at firstname.lastname@example.org.
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) <email@example.com>"
Real name: Given Surname Email address: firstname.lastname@example.org Comment: Example You selected this USER-ID: "Given Surname (Example) <email@example.com>"
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) <firstname.lastname@example.org> 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.
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.
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.
You’ll now be asked to add your name and email address. This should be self-explanatory.
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) <email@example.com>
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) <firstname.lastname@example.org>" 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! -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1 Comment: A revocation certificate should follow
iQGfBCABAgAJBQJTnwtaAh0CAAoJEE0F5u8s+gAQHMQMANH1JG5gVDnp5NY4o8ji 3j6GljQ9ieY+u3c5q0c08/uSAqGvL9jmPn1QAnikAkIJGy9kNmBJ/uC6pSMcHeCW /vYWMD/cToy63tgLOf4A8GgX2k8ttFe+DpFFSt43zbGVowykZ5AHwKImtyFwVO7M IKQZV21uFcIDl7jb5GkymkpWRZmIrexOyIAQjpyYWQT4BFFnI7kwpYyVbmodkwE/ JaC0d5dMVT9DRLr5FGuGSpzYJEeB14GCjT2EQ1js/Bji2fguFqpzM5z77FdzhS7s SNGgY8bioyjUN3CsyHMfPpkJi9mBDCV4gTxyLlVOdDiSdqA56mzjvrx3tnltfjyN kFJfPDWLqXFNpzX516oOo37b3P92bSEPcIgGeTL58nVUn/BWMsoDlIbwNyjxx7Tq YYXa2T2rbH1JHndOrmAc9X98cNrhs+vppV6SBev2MnvqobT2nqW7hKeNvwIyqunF 79fL9En2p57pQ8vH4EeRhjFSciuZZBpCEv2cMIDQGMFKVQ== =6ljf -----END PGP PUBLIC KEY BLOCK-----
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://hkps.pool.sks-keyservers.net --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.
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:
ask-cert-level <- works in lieu of the default-cert-level to ask you on each signature
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
I went to sign an outgoing message tonight and my Gemalto USB Shell Token wouldn’t light up when I plugged it into my USB port. After doing the typical troubleshooting I am left with the thought that the device has given up the ghost. This isn’t a big problem because I saved the card the SIM came out of and I’m able to use my token on my personal laptop with a traditional card reader. My work computer, however, does not have one of these fancy card readers (maybe I can find my USB one somewhere?).
I can buy another Gemalto device but I’m wondering if there is a better device to use? I mean, the Gemalto lasted almost 500 signatures. But I guess I can now take advantage of the failure to try something else. Does anyone have any suggestions?
Someone recently asked what my GPG.conf file looks like since he hadn’t updated his in… years. Okay, let’s take a look and I’ll try to explain what each setting is and why I feel it is important. I’m not guaranteeing this as being complete and I welcome input from others.
This says that if a program needs a public key but it’s not in my keyring that it should automatically reach out to the keyserver (see below) and download it.
This says to use the GPG agent. I cannot remember, right now, why this was a good idea. Perhaps it isn’t?
auto-key-locate cert pka ldap hkps://hkps.pool.sks-keyservers.net keyserver hkps://hkps.pool.sks-keyservers.net keyserver-options ca-cert-file=/etc/ssl/certs/sks-keyservers.netCA.pem keyserver-options no-honor-keyserver-url keyserver-options auto-key-retrieve
Almost the fun stuff there. This is just setting up the keyserver that I wish to use (note the use of hkps instead of hkp).
default-preference-list AES AES192 AES256 TWOFISH SHA1 SHA224 SHA256 SHA384 SHA512 Uncompressed ZIP ZLIB BZIP2 personal-cipher-preferences AES256 TWOFISH AES192 AES personal-digest-preferences SHA512 SHA384 SHA256 SHA224 personal-compress-preferences BZIP2 ZLIB ZIP
Okay, the fun stuff. These are all the algorithms that I wish to use. If you setup your GPG key to advertise these then it will make it easier for others to use the most secure algorithms since they will already know what you can do. The first line just lists all the preferences. The second, third, and fourth lines actually provide the preferences in order of them being used. If you’ll note my preferred cipher is AES with a 256-bit key and my preferred hash (digest) is SHA with a 512-bit key. There are other options available and a quick
should provide what options are available to you. For instance, my current installation says that its supported algorithms are:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
I’ve omitted 3DES, MD5, and SHA1 from my preferences due to their weaknesses but I could still use them according to my GnuPG software.
Again, this wasn’t meant to be a strict “thou must do this to be secure” but rather a “this is what I’m doing” sort of thing. I’d appreciate feedback!