Slight clarification. You don't have to reencrypt the traffic. The https decryption devices I've worked with actually hold the encrypted packet in memory for up to one second while the IPS inspects the traffic in series. If it doesn't get the unencrypted version back (the packet doesn't pass IPS), then it doesn't release the encrypted packet. I was working on a commercial product in this space, and this is an area where money is worth spending. The devices are rated based on how much encrypted traffic is to pass through them. Obviously, that is a small but quickly increasing percentage of your link to the world.
Yes, you have to put a root trust CA on your client workstations. That isn't necessarily bad, because it allows you to also ensure that the client isn't trained to click past certificate errors (which should be a disciplinable offense), but instead knows that those internal websites are okay because they are all signed properly with the same internal cert authority. How the https treats undecryptable traffic is a political decision. The decision we were trending to was issue an alert and consider having a chat with the user to find out why. It might be something as simple as a VM that the user spun up on their own and forgot to configure better. On 2014 Oct 10, at 03:40 , Edward Ned Harvey (lopser) <[email protected]> wrote: >> From: [email protected] [mailto:discuss- >> [email protected]] On Behalf Of Ski Kacoroski >> >> I need someone with more certiticate-fu than I have. I have an iBoss >> web filtering device that sits in between our internal users and the >> internet. We are trying to set it up to also filter https web pages >> which means it has to decrypt the connection to see what is going on. > > Oh god, if I worked there, I would quit in protest, and so should all your > employees. That is horrible. > > But for the sake of... whatever ... They are right. Here's how it works: > > Your client OS (or sometimes the browser itself) has a list of root trusted > CA's. So they will show green checkmarks and secure closed lock icons, for > any websites whose certs were signed by one of those trusted root CA's. > Normally those CA's will only sign certs for domains that they could follow > some reasonable process to identify the requestor as being authorized on. > Meaning, I cannot get a cert signed by any trusted CA, for the domain > twitter.com, because I cannot prove I'm authorized on that domain. > > So here's the part you need to care about. You need your own root CA, and > you need the clients in your network to trust it. So you have to create your > CA, and you have to install it to all your clients. That way, your iBoss > device can browse the internet, https://twitter.com with a signed cert from > whatever trusted root CA... Your iBoss device can decrypt the traffic, > inspect it, and re-encrypt and sign the traffic using your private root CA. > Since the clients on your network trust your private root CA, they will > display the "secure" websites. > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ ---- "The speed of communications is wondrous to behold. It is also true that speed can multiply the distribution of information that we know to be untrue." Edward R Murrow (1964) Mark McCullough [email protected] _______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
