Re: OT: SSL Inspection in Firewall

This message: [ Message body ] [ More options ]
Related messages: [ Next message ] [ Previous message ] [ Maybe in reply to ] [ Next in thread ]

From: marc edwards <renorider_at_gmail.com>
Date: Fri, 2 May 2014 19:07:28 -0700

Open SSL will generate/sign

Blogs and organic
Received

This archive was generated : Tue Jun 10 2014 - 13:43:09 ART certificates for free. dn.com/media/ZgkyMDE0LzA0LzE0LzFkL0hlYXJ0QmxlZWRQLmJlOTc0LmpwZwpwCXRodW1iCTk1MHg1MzQjCmUJanBn/0f9e6064/565/HeartBleed-Passwords.jpg">http://rack.3.mshcdn.com/media/ZgkyMDE0LzA0LzE0LzFkL0hlYXJ0QmxlZWRQLmJlOTc0LmpwZwpwCXRodW1iCTk1MHg1MzQjCmUJanBn/0f9e6064/565/HeartBleed-Passwords.jpg 2014 at 9:49 AM, Brian McGahan <bmcgahan_at_ine.com> wrote: Yeah, if your browser 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. Brian McGahan, 4 x CCIE #8593 (R&S/SP/SC/DC), CCDE #2013::13 bmcgahan_at_INE.com Internetwork Expert, Inc. http://www.INE.com -----Original Message----- From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Carlos G Mendioroz Sent: Friday, May 02, 2014 10:17 AM To: marc abel Cc: Cisco certification Subject: Re: OT: SSL Inspection in Firewall Well, the "you" have to trust means "your browser", and given that the browser's CA whitelist is quite comprehensive, this creates a big(ger) hole in infrastructure trustfullness so to say. Nothing new, but I guess I would be more at ease thinking of these as hacks than as features. marc abel @ 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> 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>> wrote: Wow... 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... -Carlos Cristian Matei @ 02/05/2014 10:24 -0300 dixit: > Hi, > You need ay type of certificate which allows you to generate > certificates, like Root, CA, Sub-CA, etc. ASA-CX is basically the Ironport > platform code, which runs on the ASA in hardware for bigger platforms or > software in lower platforms. I9m not sure if it explicitly tells you what > type of certificate you need in the documentation (I9m sure it tells you > in the IronPort knowledge base), but it tells you implicitly based on ten > behaviour/functionality. > Regards, > Cristian Matei, 2 x CCIE #23684 (R&S/SC) > 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>> 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 is that >>> 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 >>> >>> 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>> 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>> 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>> 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 Marc Abel CCIE #35470 (Routing and Switching) Carlos G Mendioroz <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 Blogs and organic groups at http://www.ccie.net _______________________________________________________________________ Subscription information may be found at: http://www.groupstudy.com/list/CCIELab.html groups at http://www.ccie.net on Fri May 02 2014 - 19:07:28 ART name="navbarfoot" title="Related messages"> [ Message body ] marc edwards: "OT: But relevant. Cisco Modeling Labs Whisper Suite" Brian McGahan: "RE: OT: SSL Inspection in Firewall" to: R.B. Kumar: "OT: SSL Inspection in Firewall" marc abel: "Re: OT: SSL Inspection in Firewall" id="options2">Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ] by hypermail 2.2.0