Late last month we reported on the vulnerability in TLS 1.0 in Keep Calm and Carry On and over at our sister blog AllSpammedUp.com in  “Holy [Insert Expletive Here]! Et Tu, SSL?”. Security researchers Thai Duong and Juliano Rizzo developed an application, called the BEAST which demonstrated the ability to capture authentication cookies protected in transit using TLS 1.0. BEAST, which stands for Browser Exploit Against SSL/TLS, was demonstrated by the pair at the Ekoparty Security Conference, and apparently caught the attention of several vendors since the vulnerability that BEAST exploits has been known for years. Remember, we care about this both because webmail uses HTTPS, and many of our email protocols can be secured with TLS 1.0. BEAST may only attack web browser traffic today, but the flaw is in TLS, which means it affects everything that uses TLS. Continue reading Vendors respect the BEAST

<sarcasm> Okay, sit down, I have some shocking news for you. TLS has been hacked, broken, smashed to bits. The technology that secures almost all of the secure Internet traffic we rely upon daily has been cracked. We’re all doomed, our bank accounts are going to be plundered, and ecommerce will come to an end. We might just as well all return to the trees; we made a good go of it, but society as we know it is done.</sarcasm>

In all seriousness though, the latest blow to the technologies that help to secure significant amounts of traffic on the Internet was delivered this week by Thai Duong and Juliano Rizzo, two security researchers who plan to demonstrate proof of concept code at the Ekoparty Security Conference in Buenos Aires, Argentina, that can actually decrypt TLS 1.0 traffic. It is a proof of concept, not a zero day exploit already developed into a Metasploit plug-in, so there’s no need to panic quite yet.

Continue reading Keep Calm and Carry On

The Internet’s Request For Comment system may be one of the world’s best examples of rule by majority consent, as it is the de facto set of ‘laws’ for how the Internet (and all its associated protocols) works, and is essentially a collection of documents that ask the world ‘what do you think about this?’

With literally thousands of documents in the collection, defining standards, recommendations, best practices, and the occasional joke, anytime you want to know the why behind how something is done, you need look no further than the RFCs. While they are replicated on countless websites, the official repository is found at http://www.rfc-editor.org.

RFCs evolve over time, and earlier RFCs can (and often will) be superseded by newer ones. There are several RFCs that address how our email protocols and the associated DNS records should work, and as an email admin, you should be familiar with the lineage of all the major email RFCs. Even those which have been superseded usually contain useful information, as most new ones define enhancements to a protocol, as opposed to completely replacing it. Over 300 of the RFCs have something to do with email; fortunately you won’t need to know them all unless you want to program a new email application. Below you will find a summary of the seventeen RFCs that email admins should have at least a passing familiarity with, and links to the online documents should you wish to read further. All links will open in a new window/tab.

Continue reading 17 RFCs Every Email Admin should Know About

One of the challenges with securing Exchange is managing its security. Exchange offers secure ways to connect to every mail protocol it offers, including SMTP/TLS, POPS, IMAPS, and HTTPS access for OWA, ActiveSync, and OWA. All of these, of course, require certificates, and that is where some admins run into problems. Exchange can generate its own, self-signed, certificates, and it will, but of course these are not trusted by clients. Admins can use certificates.msc, or certutil.exe to generate certificate signing requests, but here the challenge is generating a CSR that includes all the names and extensions required to secure all the services.

Exchange includes a wizard that you can run, which will generate a CSR with all the required properties needed for all services to run properly. Whether you submit this to your Enterprise Certificate Authority or a public CA, you can rest assured that your certificate will work for all your services. If this could be useful to you too, here is how to use the Exchange Certificate Wizard.

Continue reading The Exchange Certificate Wizard; PKI made easy

It’s important for every environment to run as securely as budgets will allow. And in these times budgets are limited so administrators and IT directors must balance the funds available with the security needs of the organization.

One component of maintaining a secure environment is that of securely sending and receiving email. However problems can occur due to incorrect settings, incompatibilities and sometimes problems with services binding to the wrong Secure Socket Layer (SSL) certificates and external URLs – which will be the focus of this article.

When administrators initially set up Exchange server they will be asked to create a self-signed SSL certificate which will be used to identify the internal NETBIOS of the machine that is used to run the server.

An issue that may result from using the self-signed SSL certificate can be observed during the connection process to an outside URL. An SSL error popup message may show up indicating that the external URL site’s https URL is not the correct site address for the SSL Client/Server socket (connection). For instance, the popup window might say something about the “https” URL, such as https://yourserver(dot)yourcompany(dot)com/, not being the correct name for the SSL Client/Server connection.

Remember that Secure Socket Layer (SSL) was originally developed as a way to secure the internet connections between web browsers and web servers. Developed by Netscape in 1994, the Secure Socket Layer can be used in other applications such as Telnet and FTP.

Continue reading Internal SSL Errors and Outlook

There have been many times in the past when I have started a project for a new customer and discovered that they are not using SSL for their email servers.  Usually after a brief discussion they agree to implement SSL in the new system we are installing for them.

Occasionally they agree but insist on doing it in a less than ideal manner.  And sometimes, although rarely, they decline our advice and continue without SSL.

What is SSL?

SSL stands for Secure Socket Layer and is an encryption protocol that secures communications between two parties over insecure networks such as the internet.  Although still commonly referred to as SSL its new name is actually TLS (Transport Layer Security) which more accurately describes its role of securing communications at the Transport layer of the OSI model (eg, the TCP protocol).

In an SSL/TLS secured communication the two parties (e.g. a web server and a web browser) agree on how to secure the connection they are establishing. Continue reading The Importance of SSL for Exchange Servers

A fix for a flaw in an important Internet security protocol is ready for prime time but it will be many months before the patch is fully implemented, according to technical experts.

The authentication vulnerability in TSL/SSL, which is the most common security code on the Net, could be exploited by hackers for all kinds of mischief. Built into browsers and Web servers to protect high-value information, the flaw impacts a wide scope of technologies including online banking, back-office systems using Web-based protocols, non-HTTP applications such as mail and database servers, mobile phones, wireless access points, DECT phones and home security systems.

The vulnerability was discovered last September by researchers at PhoneFactor, a security service provider in Overland Park, Kansas, but was kept under wraps until November when another security expert, working independently, made the flaw public on a mailing list sponsored by the Internet Engineering Task Force (IETF).

With the cat out of the bag, PhoneFactor decided to push out a press release on the subject. In it CTO Steve Dispensa, who, along with Marsh Ray, initially unearthed the flaw, stated,

“Because this is a protocol vulnerability, and not merely an implementation flaw, the impacts are far-reaching. All SSL libraries will need to be patched, and most client and server applications will, at a minimum, need to include new copies of SSL libraries in their products. Most users will eventually need to update any software that uses SSL.”

“The discovery of this vulnerability speaks to a larger issue with single channel authentication protocols,” he added. “While this vulnerability is larger in scope than many, man-in-the-middle attacks have been a known threat for some time. Out-of-band protocols should be considered when possible to help mitigate the risk of these attacks.””

Continue reading Net security hole could take year to fix

Many people have reported problems when they try to sync their cell phones with their Exchange servers.

When they try to sync with MS Exchange Server 2003 using Windows Mobile 5.0 they might get the following error code: 0x80072f17. Some users have also reported problems when trying to sync with MS Exchange Server 2007.

This problem is usually associated with using Secure Socket Layer (SSL) certificates.

Remember that you use SSL for Internet protocols such as Network News Transfer Protocol (NNTP), Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), and Internet Message Access Protocol (IMAP).

Continue reading Troubleshooting Error Code 0x80072f17

Email operations and email archiving needs to have safe and secure protocols in place, especially if the corporation is under the purview of a privacy-related piece of legislation, such as HIPAA or Sarbanes-Oxley. Generally, the best way to ensure that those privacy protocols are put in place is to avoid cloud-based email and storage services.

Google continues to try to get a seat at the enterprise with Gmail, and this week, some of the industry’s heavy-hitters took Google to the task over the issue. An open letter to Google’s CEO Eric Schmidt says the company is putting users at risk unnecessarily, and that encryption should be enabled by default on their web-based apps, including Gmail.

Currently, SSL is used only during login, after which, all browsing is unencrypted, unless the user takes an active step to return to the https protocol. Unless that step is taken, which most users will not do, the user is vulnerable to attack and theft. In most cases then, Gmail is run in the clear–which is completely unsuitable for corporate use.