Archive

Archive for the ‘Encryption’ Category

Thunderbird 45.4.0 TLS Ciphers

2016-11-09 1 comment

While working on strengthening my email server I discovered that Mozilla Thunderbird 45.4.0 only supports the following ciphers:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Not sure why it doesn’t just use the default from OpenSSL.

Update: As pointed out here and other locations, Thunderbird doesn’t use OpenSSL for its encryption library, rather it uses NSS.  This is a good example of why one shouldn’t write articles while sick.

Securing email to Gmail

2015-12-22 3 comments

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.

Update

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

RFC: Using video conferencing for GPG key signing events

2015-09-24 3 comments

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?

Categories: GnuPG Tags: ,

Encryption you don’t control is not a security feature

2015-09-23 Leave a comment

Catching up on my blog reading, this morning, led me to an article discussing Apple’s iMessage program and, specifically, the encryption it uses and how it’s implemented.  Go ahead and read the article; I’ll wait.

The TL;DR of that article is this: encryption you don’t control is not a security feature.  It’s great that Apple implemented encryption in their messaging software but since the user has no control over the implementation or the keys (especially the key distribution, management, and trust) users shouldn’t expect this type of encryption system to actually protect them.

For Apple, it’s all about UI and making it easy for the user.  In reality, what they’ve done is dumbed down the entire process and forced users to remain ignorant of their own security.  Many users applaud these types of “just make it work and make it pretty” interfaces but at the same time you end up with an uneducated user who doesn’t even realize that their data is at risk.  Honestly, it’s 2015… if you don’t understand information security… well, to quote my friend Larry “when you’re dumb, you suffer”.

Yes, that’s harsh.  But it’s time for people to wake up and take responsibility for their naked pictures or email messages being publicized.  I’m assuming most everyone makes at least a little effort toward physically securing their homes (e.g. locking doors and windows).  Why shouldn’t your data be any less protected?

In comparison, I’ll use Pidgin and OTR as an example of a better way to encrypt messaging systems.  OTR doesn’t use outside mechanisms for handling keys, it clearly displays whether or not a message is simply encrypted (untrusted) or whether you’ve verified the key, and it’s simple to use.

One thing I’ll say about Apple’s iMessage is that it at least starts to fix the problem.  I’d rather have ciphertext being sent across the network than plaintext.  Users just need to understand what the risks are and evaluate whether they are okay with those risks or not.

Postfix Encryption

2015-03-12 3 comments

I’ve been tinkering with the encryption options in Postfix for a while.  Encryption between clients and their SMTP server and between SMTP servers is necessary to protect the to, from, and subject fields, along with the rest of the header, of an email.  The body of the message is also protected but it’s always better to utilize PGP or S/MIME cryptography to provide end-to-end protection; encryption between clients and SMTP servers doesn’t provide this.

As rolled out now, encryption between SMTP servers is opportunistic encryption and is generally not required.  While doing a review of my mail log I seem to be receiving most personal mail via some encrypted circuit while much of the mail coming out of listservs, like Yahoo! Groups, is not negotiating encryption on connect.  I’ve also noticed that some email providers actually run their incoming email through an external service, I suspect for spam control, before accepting the message into their servers.  Some of these spam services don’t support encryption making it difficult to protect mail in transit.

Postfix documentation is pretty decent.  The project seems to document most settings but sometimes they don’t actually put the entire picture together.  Encryption is one of those things where a complete picture is difficult to put together just by looking at a single page of documentation.

Postfix’s documentation on TLS is fairly complete.  What they miss on that page, forward security, must be found else where.  Until last night, I had missed that last page and now have fixed my configuration to include, what I consider, acceptable settings.

Here’s what I’ve got:

main.cf

### TLS
# enable opportunistic TLS support in the SMTP server
smtpd_tls_security_level = may
smtpd_tls_eecdh_grade = ultra
tls_eecdh_strong_curve = prime256v1
tls_eecdh_ultra_curve = secp384r1
smtpd_tls_loglevel = 1
smtpd_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtpd_tls_key_file = /etc/pki/tls/private/mail.key
smtpd_tls_CAfile = /etc/pki/tls/certs/mail-bundle.crt
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_tls_received_header = yes
smtpd_tls_ask_ccert = yes
smtpd_tls_received_header = yes
tls_random_source = dev:/dev/urandom
#TLS Client
smtp_tls_security_level = may
smtp_tls_eecdh_grade = ultra
smtp_tls_loglevel = 1
smtp_tls_cert_file = /etc/pki/tls/certs/mail.crt
smtp_tls_key_file = /etc/pki/tls/private/mail.key
smtp_tls_CAfile = /etc/pki/tls/certs/mail-bundle.crt

master.cf

submission inet n       –       –       –       –       smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_sasl_security_options=noanonymous

Those familiar with setting up TLS in Apache will notice a few differences here.  We haven’t defined ciphers or SSL protocols.  This is because this is opportunistic encryption.  We’re just happy if encryption happens, even using EXPORT ciphers, since the alternate is plaintext.  In a more controlled setting you could define the ciphers and protocols and enforce their use.  Until encryption becomes the norm on the Internet (and why shouldn’t it be?) I’ll have to stick with just begging for encrypted connections.

It should also be noted that client-to-SMTP server connections are forced to be encrypted in master.cf as seen in the submission portion.  This was a quick and dirty way of forcing encryption on the client side while allowing opportunistic encryption on the public (port 25) side.

It should be noted that ECC keys can be used with Postfix, which forces good ciphers and protocols, but most email servers have RSA keys established so problems could arise from that.  Dual keys can always be used to take advantage of both ECC and RSA.

As SSLLabs is for testing your web server’s encryption settings, so is CheckTLS for checking your SMTP encryption settings.  These tools are free and should be part of your regular security check of your infrastructure.

RC4 prohibited

2015-02-19 Leave a comment

Woot!

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 post

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.