For outbound TMG needs a browser plugin. For inbound its usual to terminate the SSL on the TMG firewall and then TMG opens a new SSL session to the backend web server. For this to work TMG needs to have a copy of the certificate including the private key. Wildcard certs are commonly used with TMG but having a FQDN only guarantees the server is under control of the certificate owner. You can have multiple sites on the same server, or have a single site load balanced across multiple servers. SQUID will do the same trick, but I have always run squid on the same box as the web farm, but this isn't required... On Nov 23, 2015 5:48 AM, "Toby Thain" <[email protected]> wrote:
> On 2015-11-22 5:25 PM, Mouse wrote: > >> https is supposed to prevent "man in the middle" attacks, provided you >>> enfor$ >>> >> >> That was the original theory, as I understand it. >> >> But there are way too many "in most browsers by default" CAs that are >> willing to sell wildcard certs such as can be used for MitM attacks >> without disturbing cert validity checks. I even recall hearing of some >> caching proxy (squid maybe?) that, out of the box, could use such a >> > > Microsoft Forefront TMG maybe? > > http://itknowledgeexchange.techtarget.com/itanswers/https-inspection-within-forefront-threat-management-gateway-2010/ > > --Toby > > > cert to provide caching for HTTPS connections - they're that common. >> ... >> >> /~\ The ASCII Mouse >> \ / Ribbon Campaign >> X Against HTML [email protected] >> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B >> >> >
