Securing the Enterprise


Securing internal networks of enterprises is a very important task - for that matter any Intranet is. Today, the threats are manifold and are coming from various directions, being it through the corporate firewalls, VPN gateways, WiFi access points, compromised computers and laptops or employees and third party contractors, to mention only the most obvious. As Mr. Tom Albertson from Microsoft recently noted to me, security of any network shouldn’t be predicated on keeping the bad guys out - they are already there.

Many corporations rely on digital certificates issued by the public certification authorities to secure the point-to-point connections of their network. Unfortunately most public authorities are willing to sell “snake-oil” to those enterprise establishments instead of real security, mainly because the corporate managements request and ask for it. How come, the dear reader might ask, and what is this snake-oil made of?

It’s today common practice to assign non-qualified domain names or so-called host names to the various servers and work-stations at the corporate Intranet. Those are typically named server1.local or simply server1, whereas .local represents a non-qualified top level domain which is not assigned by the IANA/ICANN clan for public consumption. Those of you which maintain such networks or perhaps manage a small home network are probably familiar with it.

Since it’s convenient to rely on the built-in trust which comes with most software like browsers, corporations many times simply turn to their digital certificate provider and they in turn are happily distributing certificates for the server1.local and server1 family. Our trusted certification authority will do so every time they receive such a request and as a result of it, multiple certification authorities will issue the same certificate with the same host names multiple times to multiple different subjects (as a side note, it begs the question what those authorities actually verified - quite amazing really).

The result is, that if I can get a certificate for server1.local, you will get one too and so will any attacker as well. But what’s wrong with that, if the certificates are meant to be consumed just by internal networks…? Part of the answer I provided already in the first section of this article - scroll up and read it again if you forgot.

Most corporation’s Intranets rely on exactly those certificates and host names, almost without exception. From the very small home network up to the literally biggest corporations out there. Unfortunately those digital wonders sold by the public SSL certificate providers don’t provide any protection - the point-to-point encryption isn’t worth the digital paper of those certificates. That’s because an attacker can simply insert himself in between the data stream unnoticed - and that’s because he can get any of those certificates as easily from any of the certification authorities. And remember, anybody will blindly trust the compromised connection because the browser trusts the issuing authority obviously too.

How should the enterprise networks be secured instead? My solution is simple and effective. Either the enterprise relies on and manages its own CA root which is only locally trusted - or any server and computer on the network is accessed by a host name based on a real domain name. There are different implementations possible, for example:

  • domain.com (The public fully-qualified domain name)
  • www.domain.com (A public web site facing the Internet)
  • owa.domain.com (Another public Internet facing site)
  • intern.domain.com (Internal network base address - 10.0.1.0)
  • server1.intern.domain.com (The internal server - 10.0.1.26)

Alternatively a shorter path may be used, but different DNS resolution chosen for the internal and external networks. In such a scenario owa.domain.com would point to a public IP address on the public Internet, whereas at the Intranet the DNS resolution would point to an internal IP address (for example 10.0.1.26).

For both examples above certification authorities may issue digital certificates - provided that the domain name belongs to the corporation obviously. Like this, every certificate remains unique and is effectively verified to be only in the hands of those that control the domain name.

Time has come to stop the practice of fake security entirely! Mozilla has already made a first step into this direction due to a different incident and announced that it might disallow this practice explicitly. Myself took this issue to the CA/Browser Forum and I hope that the public authorities and software vendors come to an agreement very soon. Otherwise all enterprise networks which rely on such non-qualified domain names or so-called host names will remain unprotected and insecure.

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts
Are you also reading Toiletpaper?
Beat the Drum: Open Web needs to be Secure!

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

You must be logged in to post a comment. Click here to login.

Reader Comments

[…] Securing the Enterprise […]

Some helpful references to get Exchange and Outlook working with FQDN entries in the SAN:

http://www.shudnow.net/2007/08/10/outlook-2007-certificate-error/
http://support.microsoft.com/kb/940726