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.

-Carlos

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