Archive for the ‘Encryption’ Category

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:

### 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

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 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

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.


Get every new post delivered to your Inbox.

Join 262 other followers