RE: OT: SSL Inspection in Firewall from Brian McGahan on 2014-05-03 (Ccielab archives 05/2014)

From: Brian McGahan <bmcgahan_at_ine.com>
Date: Sat, 3 May 2014 02:12:51 -0500

All you do is program

Brian McGahan,
bmcgahan_at_INE.

This message:

Next message:

Maybe in

Next in

This archive was : Tue Jun 10 2014 - 13:43:09 ART the proxy not to accept invalid certs. In the chain of things your end host is the client of the proxy (ASA), and the ASA is the proxy of the real server. ASA knows if the serverbs cert is valid or not, just like any other PKI check it does for a number of applications. 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13 spam-->com<mailto:bmcgahan_at_INE.com> m">http://www.INE.com<http://www.ine.com/> [mailto:marcabel_at_gmail.com] Cisco certification SSL Inspection in Firewall if the user goes to a site with an invalid cert? You don't want to present the end user a valid cert they trust if the remote site were compromised. 2014 at 11:49 AM, Brian McGahan <bmcgahan_at_ine.com<mailto:bmcgahan_at_ine.com>> wrote: is trusting the cert then you wouldn't know the traffic is getting proxied unless you actually view the details of the cert. Also you don't need to buy a root cert, you just need to have the browsers trust your internal CA that's generating it. 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13 spam-->com<mailto:bmcgahan_at_INE.com> m">http://www.INE.com .com<mailto:nobody_at_groupstudy.com> [mailto:nobody_at_groupstudy.com<mailto:nobody_at_groupstudy.com>] On Behalf Of Carlos G Mendioroz SSL Inspection in Firewall have to trust means "your browser", and given that the browser's CA whitelist is quite comprehensive, this creates a infrastructure trustfullness so to say. I guess I would be more at ease thinking of these as hacks than as features. 02/05/2014 12:04 -0300 dixit: You usually have to consent to monitoring on any corporate network so there should be no presumed end to end confidentiality. That said, the places I know that use it do generally exclude traffic to major financial institutions like wellsfargo.com<http://wellsfargo.com> <http://wellsfargo.com> etc. and some health networks as well such as Humana. The clients have to trust the cert used on the ASA so you aren't probably going to have this done to you at a coffee shop or something. On Fri, May 2, 2014 at 9:46 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar<mailto:tron_at_huapi.ba.ar> <mailto:tron_at_huapi.ba.ar<mailto:tron_at_huapi.ba.ar>>> wrote: from the ASA-CX user guide: Configuring Decryption Settings Before you can implement decryption policies on ASA CX , you must enable them and identify the Certificate Authority (CA) certificate that the ASA CX will use to managed decrypted traf fic flows. The CA certificate is used to issue temporary replacement certificates for each site that is visited by a client application. The temporary certificate is used in place of the real server certificates in the secure (SSL or TLS) session between the client and ASA CX . Meanwhile, the real server certificate is used in the secure session between ASA CX and the server . This approach enables ASA CX to decrypt the content coming in to the device from either side, and then re-encrypt it before relaying it. Neat. Given that this breaks the (wrongly) pressumed end to end confidenciality by any one having a (white listed CA derived) CA cert, I just don't quite grasp the consecuences in the Snowden era... Cristian Matei @ 02/05/2014 10:24 -0300 dixit: > You need ay type of certificate which allows you to generate > certificates, like Root, CA, Sub-CA, etc. ASA-CX is basically the > platform code, which runs on the ASA in hardware for bigger platforms or > software in lower platforms. I9m not sure if it explicitly tells > type of certificate you need in the documentation (I9m sure it tells you > in the IronPort knowledge base), but it tells you implicitly based > behaviour/functionality. > Regards, > Cristian Matei, 2 x CCIE #23684 (R&S/SC) > cmatei_at_INE.com<mailto:cmatei_at_INE.com> > Internetwork Expert, Inc. > http://www.INE.com > On 02/05/14 08:17, "Carlos G Mendioroz" <tron_at_huapi.ba.ar<mailto:tron_at_huapi.ba.ar> <mailto:tron_at_huapi.ba.ar<mailto:tron_at_huapi.ba.ar>>> wrote: >> Cristian, >> do you have a link to a document that describes this procedure ? >> That youd need an RA certificate for the ASA, right ? Those should be >> expensive I guess :) >> TIA, >> -Carlos >> Cristian Matei @ 01/05/2014 17:37 -0300 dixit: >>> Hi, >>> >>> If you speak about ASA-CX module, if based on policies the ASA decides >>> to >>> decrypt for inspection the HTTPS session, what ends up happening >>> there will be two SSL/TLS tunnel: one between client and ASA, one >>> between >>> ASA and server. The interesting part is how do you fix the possible >>> certificate issues; the ASA needs a Root Type of certificate because >>> what >>> it does is that it gets the certificate from the server and >>> builds/generates a certificate on-the-fly to match the server9s >>> certificate attributes. So from the client perspective, the only >>> difference between the HTTPS session being decrypted or not, is the >>> server9s certificate issuer: if session is decrypted by the ASA, the >>> server9s certificate issuer will be ASA. >>> >>> Regards, >>> Cristian Matei, 2 x CCIE #23684 (R&S/SC) >>> cmatei_at_INE.com<mailto:cmatei_at_INE.com> >>> >>> Internetwork Expert, Inc. >>> http://www.INE.com >>> >>> >>> >>> >>> On 01/05/14 15:31, "R.B. Kumar" <seekumarin_at_gmail.com<mailto:seekumarin_at_gmail.com> <mailto:seekumarin_at_gmail.com<mailto:seekumarin_at_gmail.com>>> wrote: >>> >>>> Hi Experts- I am curious to understand how the SSL/HTTPS inspection is >>>> designed to be handled in Cisco ASA Firewall. >>>> >>>> What all I know is that, for SSL inspection the firewall has to >>>> de-crypt >>>> and again encrypt the traffic passing thru the firewall. Does this >>>> require >>>> the Server's Private key need to be imported into the firewall for >>>> De-cryption and Public key for encrypting? >>>> >>>> >>>> >>>> Thanks in advance >>>> >>>> RBK >>>> >>>> >>>> Blogs and organic groups at http://www.ccie.net >>>> >>>> _______________________________________________________________________ >>>> Subscription information may be found at: >>>> http://www.groupstudy.com/list/CCIELab.html >>> >>> >>> Blogs and organic groups at http://www.ccie.net >>> >>> _______________________________________________________________________ >>> Subscription information may be found at: >>> http://www.groupstudy.com/list/CCIELab.html >>> >>> >>> >>> >>> >>> >>> >> -- >> Carlos G Mendioroz <tron_at_huapi.ba.ar<mailto:tron_at_huapi.ba.ar> <mailto:tron_at_huapi.ba.ar<mailto:tron_at_huapi.ba.ar>>> LW7 EQI Argentina > Blogs and organic groups at http://www.ccie.net _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html Carlos G Mendioroz <tron_at_huapi.ba.ar<mailto:tron_at_huapi.ba.ar> <mailto:tron_at_huapi.ba.ar<mailto:tron_at_huapi.ba.ar>>> LW7 EQI Argentina Blogs and organic groups at http://www.ccie.net _______________________________________________________________________ Subscription information may be found at: http://www.groupstudy.com/list/CCIELab.html (Routing and Switching) <tron_at_huapi.ba.ar<mailto:tron_at_huapi.ba.ar>> LW7 EQI Argentina groups at http://www.ccie.net on Sat May 03 2014 - 02:12:51 ART name="navbarfoot" title="Related messages"> [ Message body ] Brian McGahan: "RE: OT: SSL Inspection in Firewall" message: Carlos G Mendioroz: "Re: OT: SSL Inspection in Firewall" reply to: R.B. Kumar: "OT: SSL Inspection in Firewall" thread: Brian McGahan: "RE: OT: SSL Inspection in Firewall" id="options2">Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ] generated by hypermail 2.2.0