• Downloads
• Example: Implementing Inspection of Outbound SSL Traffic    

• Related Topics
• Inspection of SSL Traffic Overview
• Using the SSL Private Server Key to Enable Inspection of SSL Traffic
• scio ssl
• scio const

Example: Implementing Inspection of Outbound SSL Traffic

When users in your protected network connect to HTTPS servers on the WWW, the application activity within the encrypted sessions cannot be inspected by most intrusion prevention systems. Once an encrypted session is established with the server, the user might download a seemingly harmless file or executable that contains a trojan. If this happens, an attacker could launch an attack from within the protected network.

To protect your network against this risk, you could create a firewall policy that blocks HTTPS connections from the protected zone to the unprotected zone. To protect your network and support legitimate access to the WWW, you want a solution that can inspect the HTTPS traffic.

The IDP solution supports SSL inspection in two ways:

• Using server private keys. Use this method when inspecting traffic to internal servers where you have access to the server private key.
• Using the SSL forward proxy feature. Use this method when the server private key method is not practical (for example, for traffic to servers on the WWW).

Note: If you enable both methods, the IDP Series device performs SSL inspection using the SSL forward proxy method and does not use the server private keys.

The following procedure provides the basic steps you take to implement the SSL forward proxy feature.

To implement the SSL forward proxy feature:

1. From the IDP Series device command-line interface:

   1. Generate the root certificate authority (CA) that the IDP Series device uses to create and sign new certificates used in SSL proxy operations. The following example creates a root CA:
      
      

      [root@defaulthost admin]# scio ssl ca create US CA Sunnyvale 'Juniper Networks Inc.' 'SSL Inspection policy' 'Juniper IT Services' 'admin@juniper.net' 1024

      Note: The system prompts the end user to install the CA you create in this step. Take care to configure an organization name that an end user is likely to accept, such as your company name.

   2. Verify the CA was added:
      
      

      [root@defaulthost admin]# scio ssl ca show

      serial=8E0012848A2D7CCD
      subject= /C=US/ST=CA/L=Sunnyvale/O=Juniper Networks Inc./OU=SSL Inspection
      policy/CN=Juniper IT Services/emailAddress=admin@juniper.net
      issuer= /C=US/ST=CA/L=Sunnyvale/O=Juniper Networks Inc./OU=SSL Inspection
      policy/CN=Juniper IT Services/emailAddress=admin@juniper.net
      notBefore=Jun 25 22:13:23 2009 GMT
      notAfter=Jun 23 22:13:23 2019 GMT

   3. (Optional) Distribute the CA to your users and have them install the CA in their Web browser.

      The following example prints to the screen the CA in PEM format. You can copy this text to a file that your users can import into their browsers.

      
      

      [root@defaulthost admin]# scio ssl ca export

      -----BEGIN CERTIFICATE-----
      MIIC1TCCAj4CCQCOABKEii18zTANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMC
      VVMxCzAJBgNVBAgTAkNBMRIwEAYDVQQHEwlTdW5ueXZhbGUxHjAcBgNVBAoTFUp1
      bmlwZXIgTmV0d29ya3MgSW5jLjEeMBwGA1UECxMVU1NMIEluc3BlY3Rpb24gcG9s
      aWN5MRwwGgYDVQQDExNKdW5pcGVyIElUIFNlcnZpY2VzMSAwHgYJKoZIhvcNAQkB
      FhFhZG1pbkBqdW5pcGVyLm5ldDAeFw0wOTA2MjUyMjEzMjNaFw0xOTA2MjMyMjEz
      MjNaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExEjAQBgNVBAcTCVN1bm55
      dmFsZTEeMBwGA1UEChMVSnVuaXBlciBOZXR3b3JrcyBJbmMuMR4wHAYDVQQLExVT
      U0wgSW5zcGVjdGlvbiBwb2xpY3kxHDAaBgNVBAMTE0p1bmlwZXIgSVQgU2Vydmlj
      ZXMxIDAeBgkqhkiG9w0BCQEWEWFkbWluQGp1bmlwZXIubmV0MIGfMA0GCSqGSIb3
      DQEBAQUAA4GNADCBiQKBgQDAsn2NFaXTrCpShf9sg+Ccn1rUYzPuVHTw1GUtnHHB
      o/oFXeNGETggLZ/jck+L27lOx3IpGd67yyHs08sXWvgC3MJukbl4kqyTyguy3/E9
      wkiIey8W4XzyBXrCfW2YEgMc0cFExdm+C6DrAailddTQdgelxZ7nfIj24iiBhYYM
      GQIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAFTrEz9DHcbohDJFqGWPjS+MDgsX904l
      f/WzHXftak4ZHjOryYvVaRUyitEhMX1KvMPQjYXf+TE2vF9yYqmoCj67l0Liu2ZJ
      Tw4gwy9E9p58krqvZu4F2/kVM+yEAksUIjBme1RIL6Az3kLauHvkyAbMcSFZG2b0
      7Z8WbQqn3o6s
      -----END CERTIFICATE-----
      

2. In NSM:

   1. Add IDP rulebase rules that target HTTPS traffic:

      • Match traffic flowing in the client-to-server direction.
      • Be sure to account for HTTPS over nonstandard ports. The application identification feature is not applied when the IDP Series device proxies an SSL session.
      • Include attack objects to inspect both the SSL session and the HTTP payload.

        Tip: You must include at least one SSL attack object. We recommend you include the SSL: SERVR-CERT-FAILS-VALIDATION anomaly to detect invalid certificates (that is, certificates signed by an unknown CA or that cannot be validated against the issuer CA). An invalid certificate might indicate a phishing attack. You can drop or log matching sessions.

      • Specify action and notification options.
   2. Push the updated security policy to the IDP appliance.
   3. Review logs to verify the feature operates as you expect.