If you have an intranet, you probably have links out to various sites on the Internet at large. However, you might want to rethink how you link to these sites (inspired by http://www.networkworld.com/newsletters/sec/2005/1212sec2.html?fsrc=rss-security).
From a security point of view, a click-thru on these links (or even just loading the containing page, if the links happen to be image references) sends a referrer header that is going to reveal the name of your intranet server, plus any path information from the referring URL, along with (yes) its query parameter names and values. Some or all of this information might not be the kind of thing you want recorded in the log files of Web servers controlled by outsiders.
Enforcing the use of SSL for all users on your intranet (including internal users) cuts down on (though it does not eliminate) the risk of this particular type of information leakage. True, if the outbound link itself isn't secure, it might still be requested with a referrer header (only secure requests have the header removed in all cases). But most modern browsers will at least warn a user that a page contains both secure and non-secure content. Thus, an ordinary non-secure reference to say an image located at an outside site, if dropped into a secure page on the intranet, would probably set off enough alarm bells that you would be made aware of the danger -- ad then do something to keep naive users from falling pray to it. At least in theory…
However if, like many administrators, you are only enforcing SSL at the network perimeter (for instance by allowing SSL but disallowing HTTP through a firewall), while letting users inside the network access an intranet server using ordinary HTTP connections, then the scenario described originally -- in which every outbound link risks revealing the network name and directory structure of your intranet box (and maybe even sensitive intranet query string parameters) -- becomes a very real danger.
You might say we are implicitly promoting security by obscurity here, but another way to put it is to say that we are promoting data hiding -- a pretty standard concept in computer science. Why after all allow information about your intranet to leak to the outside world, when no good purpose is served by it? Instead, consider bouncing all outbound links off an internal redirector or link proxy file. Call it something like bounce.aspx and locate it on a virtual server dedicated to this task.
This strategy really keeps the data leakage to a minimum. In addition, it allows you to examine what the users are and are not looking at on the outside, and then decide if it is worthwhile to keep all those outside links. Remember, if nobody clicks on them, what's the point of keeping them around? Particularly if the references can be moved without you being notified, thereby producing a 404?
Now, if you start to think that giving away information about your internal intranet architecture is bad, you really might want to consider looking into to Browser Helper Objects for Internet Explorer, most notably things like the Alexa and Google toolbars. The kind of things these types of toolbars report can be a tad scary. Take that idea and consider that some of your users might be installing less popular, less tested, and perhaps less trustworthy toolbars, and you have a real serious chance for a big info spill.
Let's be careful out there,
Port80