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
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.
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?
At the beginning of April, the Fedora Security Team (FST) started on a journey to close all critical and important CVEs in Fedora and EPEL that had originated in 2014 and before. Now that we’re two-thirds the way through I figured it would be a good time to see what we’ve accomplished so far.
Of the 38 CVEs (37 important and 1 critical) we originally identified: 14 have been closed, 1 is currently on QA, and 23 remain open. The 14 closed CVEs represent around a third of all the identified CVEs. So, not bad but also not great; there is still work to be done.
If you want to help get some of these CVEs cleaned up here’s a list of the target packages. We need to make sure that upstream has fixed the problem and that the packagers are pushing these fixes into the repos.
I hope to come back to you at the end of the month with a report on how all of the CVEs were fixed and who helped fix them!
Earlier this month the Fedora Security Team started a 90-day challenge to close all critical and important CVEs in Fedora that came out in 2014 and before. These bugs include packages affected in both Fedora and EPEL repositories. Since we started the process we’ve made some good progress.
Of the thirty-eight Important CVE bugs, six have been closed, three are on QA, and the rest are open. The one critical bug, rubygems-activesupport in EPEL, still remains but maybe fixed as early as this week.
Want to help? Please join us in helping make Fedora (and EPEL) and safer place and pitch in to help close these security bugs.
The Fedora Security Team (FST) has uncovered an interesting problem. Many packages in Fedora aren’t being actively maintained meaning they are unofficially orphaned. This is likely not a problem since at least some of these packages will happily sit there and be well behaved. The ones we worry about are the ones that pick up CVEs along the way, warning of unscrupulous behaviour.
The FST has been plugging away at trying to help maintainers update their packages when security flaws are known to exist. So far we’ve almost hit the 250 bug level. Unfortunately we forced a policy that still isn’t perfect. What do you do with a package that is no longer is supported and has a known vulnerability in it? Unless you can recruit someone to adopt the package the only responsible choice you have is to retire the package and remove it from the repositories.
This, of course, leads to other problems, specifically that someone has that package installed and they know not that the package is no longer supported nor do they know it contains a security vulnerability. This morning, during the FST meeting, we discussed the problem a bit and I had an idea that I’ll share here in hopes of starting a discussion.
Create a file containing all the packages that have been retired from a repository and perhaps a short reason for why this package has been retired. Then have yum/dnf consume this information regularly and notify the user/admin when a package that is installed is added to this list. This allows the system admin to become aware of the unsupported nature of the package and allows them to make a decision as to whether or not to keep the package on the system.
When I entered the information security world in late 2001 I received training on communications technologies that included a significant interest in confidentiality. Obviously the rest of the trifecta, integrity and availability, were also important but maintaining communications security was king.
Now, almost fifteen years later, I’m still focused on the trifecta with confidentiality coming out with a strong lead. But my goals have changed. While confidentiality is an important piece of the puzzle, for privacy and other reasons, I feel it should no longer be king with my work and writing.
Over the coming weeks I plan to focus on the availability of data. And not just whether or not a file is on a server somewhere but diving into the heart of the availability problem. File format standards, flexibility of the data to be used with accessibility tools, ability to translate the words into other languages to ease sharing, and the ability to move the information to other forms of media to improve access are all topics I want to cover.
I’m largely writing this as a reminder of ideas I want to research and discuss but I hope this gets other people thinking about their own works. If you have a great idea don’t you want to make it easier for other people to consume your thoughts and be able to build on them? Unfortunately the solution isn’t simple and I suspect much will be written over time about the topic. Hopefully we’ll have a solution soon before that StarWriter file you have stored on a 5.25″ floppy drive is no longer readable.