cancel
Showing results for 
Search instead for 
Did you mean: 
ittech
Level 13

Still problems with HTTPS

We are still having issues with DNS and I just have a question.

I understand there is a problem with the MWG7 resolving HTTPS URLs to IPs, but if we are hosting the DNS zone on our server that the MWG7 is pointing to for DNS should there still be a problem?

We are set up in Transparent Mode, btw.

Thanks!

0 Kudos
10 Replies
McAfee Employee

Re: Still problems with HTTPS

Sounds like there is a bit of confusion here. There isnt any problems with DNS resolution for HTTPS requests.

The client (in a transparent setup) will make a connection to the IP of the server on port 443, Web Gateway will intercept this connection. At that point it will only know the IP of the destination server. This is considered the "CONNECT" phase of the connection (in regards to Web Gateway). During this CONNECT phase the Web Gateway will typically then enable certificate verification (CERTVERIFY), at which point it will attempt to initiate its own connection to the server to determine who the server is that the client is communicating to.

This CERTVERIFY  phase allows the Web Gateway to look at certificate information, such as the common name. Typically after the certificate verification phase has taken place, content inspection would take place, this allows for inspection of full URLs, etc..

Here is an example of what might happen when you go to https://www.mcafee.com (161.69.13.40) in a transparent setup:

-CONNECT Phase: URL.Host = 161.69.13.40*

-CERTVERIFY Phase: URL.Host = 161.69.13.40, SSL.Server.Certificate.CN = *.mcafee.com

*Some browsers use SNI (server name indication), which may change the URL.Host in the CONNECT Phase.

Hope this helps or is on the right track in understanding the issue. I tried to keep this simple, so forgive any gaps in explanation.

~Jon

0 Kudos
ittech
Level 13

Re: Still problems with HTTPS

Sorry, just trying to straighten things out in my head.

At which point does the issue of not being able to connect to HTTPS sites properly happen, the CONNECT phase or the CERTVERIFY?

Or is it that the clients don't properly pass on the IP address?

Thanks a lot, Jon.

Message was edited by: ittech because I can't spell straighten Smiley Tongue on 11/7/11 1:30:48 PM EST
0 Kudos
McAfee Employee

Re: Still problems with HTTPS

Well I guess I would wonder what is the results that the user see's (what error page do you see).

But this could happen during the either, depending on the configuration.

What are some of the symptoms you are seeing? Like blockpage, access log entries, etc...

~Jon

0 Kudos
ittech
Level 13

Re: Still problems with HTTPS

As an example users are trying to go to https://www.mcafee.com (IP 1.1.1.1)

- I have specifically allowed all access with  URL matches *.mcafee.com*/Stop Cycle before authentication takes place (so anyone anywhere can get to authenticated or not)

- These users have a 13 TTL session so that they can never be disconnected from the site due to reauthentication

The clients are getting a generic "cannot display this webpage" screen from IE

Also, if they try to visit https://security.mcafee.com (IP 1.1.1.2) they get through just fine.

I've rectified the situation by adding the Destination.IP is 1.1.1.1/Stop Cycle to my rule set. I just don't know if the www.mcafee.com server rotates it's IP and the rule may not work tomorrow

If you let me know which logs to look at, I'll definitely sort through those.

0 Kudos
McAfee Employee

Re: Still problems with HTTPS

This sounds like an authentication issue, what is the TTL for the auth server session? You said 13 TTL, but what metric (seconds?) ?

It sounds close to what we talked about in https://community.mcafee.com/message/164724.

What are the actual examples for your test? I'm wondering if it has to do with the CN or the redirect after the authentication (reason for the "Fix Hostname" rule).

~Jon

0 Kudos
ittech
Level 13

Re: Still problems with HTTPS

Oops, sorry. 13 hours. It is the same problem, I was looking through the old posts, too for ideas

The actual examples are state criminal justice websites that you can't access without a proper certificate.

**https://www.hsmv.flcjn.net** - doesn't work unless IP is set for stop cycle

**https://david2.hsmv.flcjn.net** - works

Message was edited by: ittech on 11/7/11 2:41:34 PM EST

Message was edited by: ittech on 11/7/11 2:42:05 PM EST
0 Kudos
McAfee Employee

Re: Still problems with HTTPS

Is this a once a day type of issue, or is it reproducible any time?

I wasnt able to get to either of those sites. My goal was to see if the certificates used for their servers had wildcards in the CN.

2011-11-07_161453.png

You could attempt to perform rule engine tracing to see what the issue is as well. What type of transparent setup do you have (wccp | bridge | router | sidewinder)?

~jon

0 Kudos
ittech
Level 13

Re: Still problems with HTTPS

Like I said, it's a state criminal justice site so it wouldn't surprise me if they had some pretty tight ACLs. I'll try to access the site's certificate from here. We have a transparent bridge, sorry.

0 Kudos
ittech
Level 13

Re: Still problems with HTTPS

Ok the two certificates from each site look the same. One is just issued to www and the other to david2, no wildcards, other than that they are alike. The root path is the same also.

Not sure if I can reproduce the issue right now, as I would disable my other users too  

0 Kudos