IE8 SmartScreen Filter and TMG Beta 3 URL Filtering(using Microsoft Reputation Service Beta): What’s inside SSL(“query traffic”)

I’ve got “attracted” into this a while ago for amusement and from curiosity, did not have time to blog about it till now, so here is a quick blog entry.
What would you say if we take IE8 SmartScreen Filter and Forefront TMG Beta 3 URL Filtering(using Microsoft Reputation Service Beta, with Forefront TMG URL Filtering Telemetry Package installed—not that the later should influence what’s bellow-), both “querying” under SSL and take a look what’s inside SSL, what info is sent and what info will be inside the reply ?

 

As already said, looking at both IE8 SmartScreen Filter and Forefront TMG Beta 3(using Microsoft Reputation Service Beta), I’ve seen that the “query traffic” is protected with SSL(actually Microsoft mention this if you access some of the links bellow). But that should not make our work much harder.

Using Wireshark, I’ve observed, on my side, that:
- IE8 SmartScreen Filter queries for an URL: urs.microsoft.com.
- Forefront TMG Beta 3 URL Filtering queries for an URL: ds.beta.msas.microsoft-int.com.

 

IE8 SmartScreen Filter

We may expect this service to be a more “economical” service, small queries and small answers, tell us if an URL represent a threat or not for us. You may like to read:
http://www.microsoft.com/windows/internet-explorer/privacy.aspx

I’ve noticed that, this are just observations and they should be treated accordingly, it looks it has a sort of a cache which it builds dynamically based on the web sites I access(query the service and cache the response) and a "default" URLs list(apart from the heuristic thing, we're not interested about such aspects, rather just what it sends over SSL when it queries for an URL).
It does not seem to check web sites like google.com, microsoft, wikipedia.org, etc., or at least some parts of them.
If I visit a web site that is not as the ones mentioned above, I saw it making a query for the accessed URL. The response seems to be cached, if I visit later the same URL, it does not look like it will query again.

You may like to read:
http://windowshelp.microsoft.com/Windows/en-US/help/88c0193b-ccdc-4242-90d3-bce75f4368b71033.mspx
http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-iii-smartscreen-filter.aspx
http://download.microsoft.com/download/2/8/e/28e60dcc-123c-4b27-b397-1f6b2b6cb420/Part1_MM.pdf

I somehow question the "real-time" protection of the service though. For example, one time, it seems I've introduced some "latency", so when I've visited a "malware" web site, IE8 displayed for a second the web
page and then quickly displayed the red warning page to not continue to that web site because it's unsafe, while normally I should have seen the red warning page first. Well, for a second it looked I've already been
on that web site..., if malware was on that page, then what ?

So let’s say I want to access a web site known for being unsafe, here is the request made by IE8 SmartScreen Filter for that, note the details about the computer on which I was using IE8 and the URL that I want to access:

ie_req1

 

And the response received for that query, note that it contains a ‘MALW’ string possibly indicating we are visiting a web site containing malware:

 

ie_resp1

Which will make IE8 to notify us that we are visiting un unsafe web site:

ie_unsafe

 

So we were blocked from accessing that web site.

 

Say now I access a “safe” web site, www.isaserver.org and attempt to read an article posted there, the query:

ie_req2

The response, note that it contains an ‘UNKN’ string, so it looks like it does not say the URL is known as being safe, rather just unknown:

ie_resp2

Also they check "HTTPS URLs", which raises a little the privacy concerns as the actual URL should be protected by SSL and known only to the browser and web server, but it is sent to Microsoft.

Query “HTTPS URL”:

ie_req3

Response for the above “HTTPS URL” query:

ie_resp3

 

As we can notice from the server’s responses, the server(s) seem to run IIS 6.0.

 

Forefront TMG Beta 3 URL Filtering(using Microsoft Reputation Service Beta, with Forefront TMG URL Filtering Telemetry Package installed)

Here things become more interesting, please keep in mind that these is still beta stuff. First you may like to read:

http://www.microsoft.com/Forefront/edgesecurity/isaserver/en/us/MRS-privacy.aspx
http://www.microsoft.com/Forefront/edgesecurity/isaserver/en/us/TMG-privacy.aspx

Why I’ve mentioned the “more interesting” words ?
Because of the concept used to implement this feature. Things feel more well engineered. Obviously this(the URL filtering) is a more complex service and serves a more complex purpose.

Forefront TMG Beta 3 URL Filtering uses a local cache that it builds based on the URLs accessed by the users behind it(cache entries are subject to a time-to-live value).

You may like to read:
http://blogs.technet.com/isablog/archive/2009/06/10/url-filtering-is-here.aspx
- Announcing the Availability of Forefront TMG URL Filtering Telemetry Package

Let’s take a look, request for an URL, as can be noticed, we cannot see anymore this URL in plain text, looks like they use a hash function to hash it, and some info about my TMG Beta 3 machine is sent, the information is now somehow harder to digest:

mrs_req

And here comes the response, also this is harder to digest, we can’t see in “plain”(name or something like that) the category to which the queried URL belongs:

mrs_resp

 

 

 

As we can notice from the server’s responses, now the server(s) seem to run IIS 7.0.

 

And here is an interesting question that I've received the other day, do you still need to keep the IE8 SmartScreen Filter enabled on clients behind Forefront TMG Beta 3 if you enable on Forefront TMG Beta 3 the URL Filtering, the HTTPS Inspection, the Malware Inspection and the NIS ?
Sure, keep it enabled, unless you have a good reason to disable it or so and one more time, keep in mind that Forefront TMG is still in its beta stages, so be careful where and how you deploy it.

Pingbacks and trackbacks (1)+

Comments are closed