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.

BEAST uses a combination of JavaScript and a network sniffer to capture traffic, but can only decrypt traffic protected by TLS 1.0. Successors that are not vulnerable include TLS 1.1 and 1.2, which have limited support in most browsers as well as with most web servers. But now that the world has seen a practical attack against this vulnerability, major software companies are starting to devote resources to fixing this problem.
TLS 1.0 is broken; there is not a patch to fix its flaw. The best remediation is to stop using it, and to start using its more secure successors in the .1 or .2 version, but with so many incompatibilities in browser and webserver, this is easier said than done. The response from vendors has been mixed, with no clear and comprehensive fix in place yet, but here is what we’ve learned so far*.

Microsoft

Microsoft released Security Advisory 2588513 and has announced that they are working on an update that will disable TLS 1.0 in client operating systems, and enable 1.1 and 1.2. This can be done now manually, but may be beyond the typical home user and significant work for corporations with thousands of PCs. By making these changes in the operating system (instead of in Internet Explorer) any browser will be protected. They have also published a blog post that details how Windows admins can set TLS 1.0 to favour the RC4 cipher over the vulnerable CBC cipher in TLS 1.0. While not disabling the vulnerable cipher completely, this will protect the majority of clients, most of which will support this encryption suite. They also have automated ‘Fix it’s on that blog post, and a link to deploying this through a GPO.

Google

Google’s current version of Chrome does not support TLS 1.1 or 1.2, but the company has released both a dev and a beta version of their Chrome web browser designed to circumvent the vulnerability in TLS 1.0. It is likely this will move to the general release soon.

Mozilla

Mozilla maintains that their browser cannot be exploited by BEAST because of the way Firefox handles connections that originate in the browser, but they are also urging users to disable JavaScript.

Opera

Opera started to implement only TLS 1.1 and 1.2 in the latest release of their browser, only to find that it was incompatible with thousands of websites that can only use TLS 1.0. In a blog post they have shared the efforts that they are taking to find an appropriate work around that doesn’t require changes to websites, or that introduces incompatibilities with them.

Symantec

As the parent company of Verisign, one of the largest Certificate Authorities, Symantec is looking at ways they can leverage their leadership in the market to encourage other vendors to respond.

It appears that at this time, there is no easy way to fix this problem, but again, take heart in the following.

BEAST is proof of concept code; there is no indication that there is currently any “in the wild” attack that takes advantage of the vulnerability in TLS 1.0 using CBC.

Most experts agree that to successfully use BEAST, a significant degree of compromise would already have happened, or in other words, an attacker would already be on your network, able to inject JavaScript into your browser, and sniff your network traffic. If that is the case, you have more problems than compromised cookies.

Disabling JavaScript may not be a palatable answer, but is an effective one.

Closing all browser sessions before opening a new browser to access a secure website directly, and the closing that browser before accessing any other sites with another fresh browser session, is an effective protection.

We will continue to monitor developments and will post another article on this issue if anything significant is announced.

*Apple’s support site was down at the time this post was written, and I could find nothing specific elsewhere to indicate anything is being done around Safari or iTunes.

Vendors respect the BEAST

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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

TLS 1.0 is one of the most commonly used encryption protocols for securing traffic, including HTTPS, SMTP/TLS, and secure versions of POP3 and IMAP. We use it whenever our clients access our email servers using any secure protocol including web mail, and when we send TLS protected mail between our systems and our partners.

Defined in RFC 2246, it was proposed as a replacement for SSL 3.0, which is actually still widely used today. TLS 1.0 is a Cipher-block chaining protocol, where a block of plaintext is XOR’d with the block of ciphertext that precedes it. BEAST uses a type of cryptologic attack called a “known plain-text” attack to figure out the encryption, exploiting a vulnerability in TLS 1.0 that has long been theorized as a problem with the protocol.

TLS 1.1 and 1.2 both exist as successors to TLS 1.0, and neither are vulnerable to this same flaw, but have not been widely implemented in part because the flaw in 1.0 wasn’t real, at least, not until now. Internet Explorer can use both, but they must be enabled. SChannel in Windows 2008 and 2008R2 can use them as well, but again, must be enabled. The easiest way to do this domain wide for Windows users is to use a group policy to enable “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing”, but don’t do that just yet. This can have some undesirable effects on a typical PC. Read this KB article and test carefully before making a system-wide change like this, and then keep in mind that Chrome, Firefox, and most other browsers cannot use TLS 1.1 or 1.2 at the time of this writing. Even with Windows software, this setting is advisory only. It enables them to use TLS 1.1 and 1.2, but it doesn’t force them to. Many websites using HTTPS only implement TLS 1.0, and clients will be able to fall back to that.

The duo’s proof of concept application is called BEAST, for Browser Exploit Against SSL/TLS, and apparently does to a very effective job of decrypting authentication cookies used by websites to grant users access to secured content that requires authentication. Apparently the attack works like this: a bit of JavaScript is injected into a user’s browser session when they visit a compromised website or click on a link that takes them to a site set up to deliver the code; it then works with a network sniffer to capture encrypted cookies passed between the client and a server, which it is then able to decrypt.

To exploit a system, an attacker must first deliver the JavaScript to the browser, and then must have a sniffer in place to capture the packets. A well patched system, running current antivirus, and protected by mechanisms like a proxy server, should be difficult to attack. If an attacker can do all of that to a user, they can probably do anything else they want already, which means they probably already own the victim’s computer.

The good news is that the exploit for this vulnerability, and the proof of concept application, were both developed by good guys. By demonstrating that this sort of attack possible and practical, it will likely motivate developers of browsers and web servers to deploy TLS 1.1 and 1.2 capable versions of their software. Google has already released a patch that, while still using TLS 1.0, defeats this particular attack, and the developers of OpenSSL and the Network Security Services libraries used now have real reasons to implement the stronger protocols.

So, what can be done to help mitigate this? Follow the points below:

1. Keep up-to-date on all vendor patches, both for your operating system and all applications you use.
2. Keep antivirus software up-to-date, use real-time scans, and perform scheduled full scans regularly.
3. Close all browser sessions, and use a fresh session with no other open tabs whenever you need to browse to a secure site, like your bank, credit card, webmail, etc.
4. Close that browser completely when you log off.
5. Consider disabling JavaScript in your browser.
6. Consider using a sandboxed version of a browser.
7. Watch for, and implement, updated libraries for encryption as soon as they are available from your vendors.

In researching for this article, I came across a handy website that can show you just which protocols your browser uses to secure an HTTPS session. It uses a self-signed certificate, so be ready to get a warning dialog, but check out https://www.mikestoolbox.net/ to see some interesting information about your browser, and to test any changes you make to supported encryption protocols.

Keep Calm and Carry On

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.

DNS

The DNS records that support email include MX records, PTR records, SPF and Domain Key records. Each record format is defined within these RFCs. Here are the main RFCs concerned with DNS.

rfc 974 Mail routing and the domain system (MX records)

rfc 4406 Sender ID: Authenticating E-Mail

rfc 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1

rfc 4871 DomainKeys Identified Mail (DKIM) Signatures

SMTP

The Simple Mail Transfer Protocol has evolved multiple times throughout its history, but each newer RFC ensures backwards compatibility with its predecessor.

rfc 821 Simple Mail Transfer Protocol (SMTP)

rfc 822 Standard for the Format of Internet Messages

rfc 2821 Simple Mail Transfer Protocol (SMTP)

rfc 2822 Internet Message Format

rfc 5321 Simple Mail Transfer Protocol (SMTP)

POP3

The Post Office Protocol has gone through a few iterations. Currently we are up to v3. You can review the RFCs for the earlier versions if you’d like to, but here are the ones relevant to the current version.

rfc 1725 Post Office Protocol Version 3

rfc 1939 Post Office Protocol Version 3

rfc 2449 POP3 Extension Mechanism

rfc 5034 The Post Office Protocol Simple Authentication Mechanmism

IMAP

Like POP, IMAP has gone through several iterations. The current one is IMAPv4.

rfc 3501 Internet Message Access Protocol v4

Security

While there are several RFCs that address various security mechanism within email, here are some of the ones you have probably dealt with or will deal with in your duties.

rfc 1991 PGP Message Exchange Formats

rfc 2246 TLS Protocol

rfc 2595 Using TLS with IMAP, POP3 and ACAP

Being familiar with the RFCs helps you understand what goes on between client and server or between server and server, and also reveals just how products from diverse manufacturers, running on many different operating systems, can still interoperate, making the exchange of messages and files possible.

There are several others related to email; which have you found most useful?

17 RFCs Every Email Admin should Know About

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.

1. Here is how to use the Exchange Certificate Wizard.
2. Launch the Exchange Management Console.
3. Browse down to Server Configuration.
4. Select the server you are going to configure.
5. From the Actions pane, click the New Exchange Certificate… to launch the wizard.
6. In the first step, give the certificate a friendly name which will help you to identify it whenyou go to assign it to services, then click Next >.
7. You are then prompted to enable a wildcard certificate. If you want to purchase a wildcardcertificate from a public CA, this is a great way to leverage one certificate for several purposes, especially when you are using a load balancer or securely publishing sites through TMG 2010. Just make sure you are purchasing the proper number of licenses based on the agreement with your CA. If you are not going to use a wildcard certificate, just click Next >. In this example, that’s what we’re going todo.
8. In the next step, you can select each of the services you want to use with your Exchange server. The first choice, Federated Sharing, indicates that you must use a Public certificate, on the basis that your Federation partner will not trust your internally issued certificates. You can also enable Client Access server for OWA and ActiveSync, Web Services, Outlook Anywhere, and Autodiscover, Client Access for POP and IMAP, and Unified Messaging. There are also options for your Hub Transport server and Legacy Exchange server. Where relevant, you can enter both your intranet and Internet names, so that your one certificate can be used both internally, and on the web. Since certificates cost money, but they cost the same no matter which services you enable the names for, I recommend that you go ahead and activate all the ones you might possibly use. That way, you are covered as you enable more services later. After you enable the desired services and enter your intranet and Internet names, click Next >.
9. Pick the name from the list that you want to populate in the certificate as the CN= property. Usually, this will be the NetBIOS name of your server, then click Next >.
10. Fill out your Organisation, Organisational Unit, Country from the drop down list, your City, and your State (remember to spell it out, no abbreviations here.)
11. Browse to the location you want to save your CSR to, and give it a name. I usually use my Desktop so it is easy to find. Click Next >.
12. Verify the information in the last page, and click New. You will see the CSR listed under Exchange Certificates. Note that an incomplete CSR will not show a checkbox.
13. Now, submit this CSR to your CA of choice, and when the certificate is issued, use the Complete Pending Request wizard to enroll the certificate. Launch that by right-clicking the pending certificate, and clicking Complete Pending Request…
14. Follow the steps in this wizard, browsing to the issued certificate. When completed, this certificate will now show a check box under Exchange Certificates.
15. Right-click it again, and launch the Assign Services to Certificate… wizard. Make sure only to assign it to those services you selected when you created the CSR.

And once the certificate is assigned, you should be good to go. I usually restart the services just to be on the safe side, but you should not have to reboot unless you want to take the easy way out. Of course, if you run your updates at the same time (and since this is maintenance window work, that’s probably a good idea) then a reboot will be needed any way, and it’s less work overall.

As you can see, Microsoft has come a long way in making PKI work easier for admins. While some folks really dig getting into the nitty-gritty of PowerShell commands, the rest of us can use the time saved to do other things, like sleep.

The Exchange Certificate Wizard; PKI made easy

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.

SSL is an excellent security technology with a number of uses. From a user perspective it is most often seen as a front end to the Hyper Text Transfer Protocol (HTTP) in the form of HTTPS. It can also be used for POP3, SMTP, IMAP, and just about any other well behaved TCP application. It’s very easy for most programmers who are developing network applications from the start to just pull down an SSL implementation and integrate it with their application to provide encryption when communicating across the network via TCP.

And a lot of times, when certificates are needed for Exchange server, some administrators will just use the self-signed certificate that is created during initial setup. An option that administrators should consider is to purchase a certificate from an outside authority, known as a Root Certificate Authority. Certificates can be purchased from such authorities as: Verisign, GlobalSign, Thawte, and others.

But even after installing a valid certificate administrators may find that they are still receiving popup error messages about SSL errors and those error messages still refer to the aforementioned URL as not being a valid name for the SSL Client/Server connection.

It helps to know that all communication in an Exchange server environment is expected to run through SSL encryption. Meaning that communications between Exchange servers is encrypted and that communications between Exchange and Outlook clients is also encrypted. But you may have thought that those communications were supposed to be using RPC and MAPI. That still happens but only for some services.

Other services are using HTTPS. For example when Outlook 2007 is started up it will use an “Autodiscover” service to locate the mailbox for a user on an Exchange server. Normally this service is configured at setup time. The “Autodiscover” service uses SSL encrypted “tunneling” to the Exchange server for its communications.

(Tunneling, or port forwarding, is a way to forward otherwise insecure TCP traffic through SSH. You can secure POP3, SMTP and HTTP connections that would normally be insecure. I have used tunneling when working at remote customer sites and I was behind a firewall but I needed to get access to my own network.)

Getting back to our story, most Client Access Server Role services are bound to the SSL certificate you configured in Internet Information Server for the default website and which are subsequently by Exchange services for the sub sites. In order to correct this situation a reconfiguration will need to be performed that will bind all services to use the newly installed SSL Certificate – pulled down from one of the aforementioned Root Authorities – and to the company’s outside URL web site.

The Exchange information can be changed using cmdlets commands in the Windows PowerShell environment. The Windows PowerShell runtime can invoke these cmdlets from within automation scripts or invoke them through the Windows PowerShell APIs from via software.

The cmdlet that an administrator can invoke is as follows:

Set-WebServicesVirtualDirectory -Identity “(Virtual Directory ID)” -ExternalUrl “Https://(hostname to connect to Exchange server from outside the firewall)/” -InternalUrl “Https://(hostname of Exchange server for connection from inside the firewall)/”

This command will update all of the service addresses such as: OAB, Free/Busy, OOF, GAL.

If you are interested in updating only the Autodiscovery SCP you can use the following CMDLET:

Set-ClientAccessServer -Identity Servername -AutoDiscoverServiceInternalUri https://yourserver(dot)yourcompany(dot)com/

This cmdlet can be used to support the certificate which you purchased earlier and to sidestep Autodiscovery service errors as seen in such Exchange server environments.

Internal SSL Errors and Outlook

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.The server sends the client its public encryption key (sometimes known as an SSL certificate) which the client then verifies against its own list of trusted certification authorities.  Once it has verified the key the client will generate a random number, encrypt it with the server’s public key, and send it to the server.  The public key encryption ensures that only the server can read the random number.

Contrary to popular assumption it is not the server’s public key (or SSL certificate) that is used for the encrypted connection, rather it is only used to secure the initial exchange of the random number.  The random number is then used to encrypt and decrypt the actual connection traffic.

Why is SSL important for Exchange Servers?

Exchange servers come with useful remote access features such as Outlook Web Access, Outlook Anywhere, and ActiveSync.  These features allow your users to access their email from any location with an internet connection by using a web browser, their laptop, or a mobile device such as a smartphone.

This convenience carries with it some security risks, the most obvious being the risk of password credentials being compromised.

Operating any of these remote access services without SSL means that the connection, including password credentials, occurs over an unsecured HTTP connection.  HTTP is the protocol that most websites use.  It is fast, stable, and works through just about any firewall.  But HTTP has no built in security.  Every bit of data sent over HTTP is unencrypted, so when passwords are sent over HTTP they are sent “in the clear”, vulnerable to network sniffers.

Because so much of this remote access occurs from untrusted locations such as free wireless hotspots, it is critical that SSL be used to protect this traffic.

Recommendations for using SSL

Here are some recommendations for using SSL to secure your Exchange server’s remote access features.

• Make it mandatory, not optional.  If you enable SSL but also still allow unencrypted HTTP you make it possible for an unwitting user to connect over the insecure method.
• Use it internally as well as externally.  It is tempting to allow non-SSL connections from locations within your own corporate network but this is still risky.  Some security professionals consider all network segments to be untrusted.
• Use a commercial Certificate Authority instead of a private one.  You may be tempted to save money on SSL certificates by installing a private CA and issuing your own, but this causes more headaches than it is worth.  Your private CA will not be trusted by devices such as smartphones or non-corporate computers, and will result in SSL warning messages that confuse users and can make some applications refuse to connect at all.  Because the SSL warning messages are also often found with phishing sites like fake banking sites it is not a good idea to get your users used to ignoring them.

The Importance of SSL for Exchange Servers

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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

According to a U.S. Computer Emergency Readiness Team (CERT) vulnerability note, the TLS/SSL defect exploits the way the protocol handles renegotiation requests.

“The server treats the client’s initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data,” it explained.

The note said that SSL and TTL protocols are commonly used to provide authentication, encryption, integrity, and non-repudiation services to network applications such as HTTP, IMAP, POP3, LDAP. A vulnerability in the way SSL and TLS protocols allow renegotiation requests may allow an attacker to inject plaintext into an application protocol stream.

“A remote, unauthenticated attacker may be able to inject an arbitrary amount of chosen plaintext into the beginning of the application protocol stream,” it added. “This could allow and attacker to issue HTTP requests, or take action impersonating the user, among other consequences.”

What’s more, the attack is invisible to the server and browser it’s directed at, according to PhoneFactor. They have no idea that a session has been hijacked.

Following the public revelations about the TLS/SSL glitch, a working group was formed made up of vendors and representatives from the appropriate standards committees. They hammered out the fix for the problem that was released last week.

Vendors are expected to begin shipping patches containing the fix shortly. However, predictions are that adoption will be slow because patches must be performed on both servers and clients to fully close the security gap. “This obviously will not happen tomorrow,” Ray Marsh wrote in his Extended Subset blog, “but eventually clients and servers will have to start refusing connections with unpatched endpoints (just like they do with ancient versions of SSL today). i.e., their configuration needs to go from “insecure/compatible mode”to secure/strict mode.”

“Unfortunately, as long as there is a single unpatched client and a single compatible-mode server in the world (or a compatible-mode client and an unpatched server) there exists a potential vulnerability,” he added.

Because the patching process will be prolonged, Marsh recommends that steps be taken to ensure that Web surfers are aware of their security status when accessing servers on the Net.

“[In the coming months we will need client applications to begin warning users if they are connecting to an unpatched server,” he noted. “After all, wouldn’t you expect your browser to warn you if your connection could be hijacked because the (supposedly) secure site to which you were connecting was not maintained well enough to apply critical security patches on a regular basis?”

Net security hole could take year to fix

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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

The SSL authentication method uses public/private key technology to ensure privacy. The SSL protocol resides at the Open Systems Interconnection (OSI) presentation layer and moves data from the application layer to the TCP transport layer. It is responsible for authentication, encryption, and verification of data integrity.
The authentication function assures that the data is being sent to the correct server and that the server is secure. Encryption ensures that data cannot be read by anyone other than the target server. Data integrity ensures that the data has not been corrupted or altered in transit.

If your user removes the SSL authentication then they’ll probably be able to synchronize their phones with the server. But that’s probably not how you want them to operate. Even if you directly install the certificate you may still have problems. Checking or un-checking the proxy settings related box does not have an effect on the problem.

One solution to this problem is to reissue the SSL certificate through Internet Information Services (IIS). This can happen if you were using the original certificate the Exchange Server installed and the certificate was replaced.

Another possible cause for the 0x80072f17 error is if an unsupported certificate has been installed. If you installed a certificate that supported wildcards from a certifying digital certificate provider, then this certificate will probably install but using the certificate was most likely not supported. To fix this problem you can replace the certificate with one that does not use wildcards and is listed in the root certificate store on the device.

Another situation when the problem can occur is when Microsoft Exchange does not connect but generates another error code: 0x80072EE7. Selecting another system to synchronize with will result in a related synchronization error message such as when the Microsoft Exchange server shows “Synchronization could not be completed. Try again later”. The support code generated by the system is: 0x80072F17.

You might need to add a new certificate to your device. Such as when your SSL certificate issuer on the Exchange Server is new to the business or has made some changes.

Here’s how you can enable and disable Outlook Web Access for internal clients:

If you are using Microsoft Exchange Server 2003 Service Pack 1 (SP1), the following steps do not apply. The Web DAV address check is not present in Microsoft Exchange 2003 Service Pack 1.

To restrict access to Outlook Web Access if you are using Exchange Server 2003 SP1 or later, follow these steps:

1. In the Active Directory Users and Computers snap-in, right-click the user account that you want to restrict from using OWA, and then click Properties.
2. Click the Exchange Features tab, click Outlook Web Access, and then click Disable.

By default, user accounts that are mailbox-enabled are also enabled for Outlook Web Access in Exchange Server 2003.

You can enable users in your corporate network to access Outlook Web Access. At the same time, you can deny access to external clients. The key to this approach is a combination of a recipient policy and a special Hypertext Transfer Protocol (HTTP) virtual server.

To use this approach, follow these steps:

1. Create a recipient policy with a Simple Mail Transfer Protocol (SMTP) domain name. Users who connect to an HTTP virtual server must have an e-mail address with the same SMTP domain as the virtual server. Creating a recipient policy is an efficient way to apply the same SMTP domain to multiple users. (Note Outlook Web Access users do not have to know the name of the SMTP domain.)
2. Apply the recipient policy to the user accounts that you want to enable access for.
3. On the front-end server, create a new HTTP virtual server that specifies the domain that is used in the recipient policy.

After you have completed these steps, users whose e-mail addresses do not have the same SMTP domain as the HTTP virtual server cannot log on and access Outlook Web Access. Also, as long as you do not use the SMTP domain as the default domain, external users cannot determine what the SMTP domain is because the domain does not appear in the From field when users send e-mail messages outside the organization.

For more information, review the following article number in the Microsoft Knowledge Base:  293386  HTTP 401 or 404 error messages when you access OWA implicitly or explicitly.

Besides enabling Outlook Web Access for users in your corporate network, you can also prevent specific internal users from accessing Outlook Web Access. You do this by disabling the HTTP and Network News Transfer Protocol (NNTP) protocols for those users.

To prevent an internal user from accessing Outlook Web Access, follow these steps:

1. In the Active Directory Users and Computers snap-in, open the user’s Properties dialog box.
2. On the Exchange Features tab, click Outlook Web Access, and then click Disable.
3. Restart the IIS Admin Service.

Troubleshooting Error Code 0x80072f17

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

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.

Google should encrypt the cloud

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators