Showing results for 
Search instead for 
Did you mean: 
Level 12

Dynamically Stop Cycle when embedded protocol isn't SSL

Pretty sure that the answer to this will be No.

Is there any mechanism to dynamically implement SSL Bypass for a destination if the SSL protocol negotiation fails?

For example, in a destination network there is a mixture of compliant and non-compliant SSL (Citrix, etc.) destinations. I want to use SSL Scanner whenever possible, but if I don't know in advance which servers are running what applications, I have to either Stop Cycle for the entire destination network or implement SSL Scanner for that network and then implement exceptions as specific destinations are identified as non-compliant.

If there was a way to tell MWG to intercept the SSL connection, but to drop to Stop Cycle if the protocol negotiation fails or the data isn't compliant with the protocol that would make it so that if a connection can be intercepted, it will be, but if it cannot be intercepted, it won't fail.

0 Kudos
4 Replies
McAfee Employee

Re: Dynamically Stop Cycle when embedded protocol isn't SSL

Once the SSL connection has been opened up, there isnt a way of going back.

Specifically with Citrix have you seen the subscribed list functionality? For more info see here:



0 Kudos
Level 12

Re: Dynamically Stop Cycle when embedded protocol isn't SSL

I've seen the subscribed list functionality -- the situation that I'm looking at doesn't quite fit into that realm.

It's probably technically feasible, but I will grant you that it wouldn't be simple to implement at the code level -- there would need to be a way to notify the client to stand up the connection again and MWG would have to then remember for a certain period of time that the source and destination involved should fall into a bypass mode.

0 Kudos
Level 17

Re: Dynamically Stop Cycle when embedded protocol isn't SSL


from MWGs perspective it should be possible to have a chance to remember a connection and treat it differently if the client retries within a specific amount of time. However MWG will not have a chance to tell *any* client to "try again". There is no common mechanism to do this that is understood by any client.

It could be possible to try something like

- Accept SSL connection from client

- Try if SSL connection with server works

a) if it works - fine

b) if it does not work:

- store the information about source ip/destination IP for a period of time

- send a 302 to the same URL

If the client follows the 302 it would contact the same URL again. MWG sees client and destination IP it has remembered and will now bypass SSL Scanner.

But there are many many aspects to consider:

- If the client checks for the server certificate it will not work

- It may be different in transparent environments

- There must be a reliable technique to remember the IP pairs (PDStorage is probably not reliable enough)

- ...

Probably worth playing around with the idea, at least it sounds interesting :-)

0 Kudos
Level 7

Re: Dynamically Stop Cycle when embedded protocol isn't SSL

Interesting, indeed. I would love to see this followed up to by McAfee (@Andre, looking at you :-) ).

0 Kudos