Face book blocking, through Application Control..

Bill, if the Astaro is to examine encrypted traffic, doesn't it have to do a man-in-the-middle decyption/encryption in order to see the L7 content?  How is that possible without the hassle of the same configuration necessary to set this up in the HTTP/S Proxy with the 'Scan HTTPS (SSL) Traffic' box checked, Exceptions created, CAs up/downloaded, etc.?  I don't understand how it could "just work."

That said, I'm the first to admit that there's a lot I don't know!

Cheers - Bob

Bill, if the Astaro is to examine encrypted traffic, doesn't it have to do a man-in-the-middle decyption/encryption in order to see the L7 content?  How is that possible without the hassle of the same configuration necessary to set this up in the HTTP/S Proxy with the 'Scan HTTPS (SSL) Traffic' box checked, Exceptions created, CAs up/downloaded, etc.?  I don't understand how it could "just work."

That said, I'm the first to admit that there's a lot I don't know!

Cheers - Bob

.. I'm the first to admit that there's a lot I don't know...

Bob, you are the master of it all and its refreshing to see people like you that are humble and gracious while they know it all.

I am not arguing  L7 case against encrypted traffic and fully agree that if astaro can't see the traffic, it can't block it. I guess my post was more of wishful thinking on my part than anything else. And yes if there was some magic software that could encrypt/decrypt traffic without the client knowing about it and be the man in the middle like you call it, that would be great. 

Regards
Bill.

Hello,

The problem is that Astaro hooks the proxies combined + globally; e.g. the SSL and HTTP proxy. To have the app control work per signature you have to hook the proxies per rules. That implies to unify the firewall approach.

To block “encrypted” traffic by signature can be easy and does not mean you have to always decrypt; it may vary per traffic.

And I respectfully beg to differ, blocking is not the same with filtering. [;)]
E.g. filtering can apply to safe search where you actively intercept and modify l7 content, while blocking of an app using l7 does not necessarily have to modify any l7 content or even see/proxy it.

Consider the facebook over SSL block. SSL normally provides little peer identity protection + limited traffic flow confidentiality; e.g. one is able to see the identity of the server in server’s cert. All you have to do is to activate a detection rule based on a couple of factors: e.g. TCP + srv port 443 + srv cert containing a specific CN or SAN DNS + optional client SNI srv name. The difference between this and a proxy is that a partial protocol analyzer is used(e.g. for SSL structure, identify cert and extract srv name to match).
In fact with a little bit of heuristic you can even tell what proto is inside SSL.

Same for other apps like Skype which uses proprietary encryption; you do not have to decrypt to identify it. That’s why it appeared the allow Skype + global HTTPS proxy problem in the first place.

To unify the firewall approach means to create all rules in one place; e.g. first place the rules that allow/block apps(yes, the app is added directly into the fw rule) without the need of SSL insp, then place the rules that require SSL inspection. Also the proxies are “decoupled”, e.g. if you decrypt SSL you do not have to hook thereafter the HTTP proxy too all the time on port 443. You may need to decrypt SSL for granular app rules(e.g. block only a certain app feature) but does not mean you have to proxy HTTP too.

Thanks,
Adrian