Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Guide That Contains This Content
[+] Expand All
[-] Collapse All

    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' '' 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
        subject= /C=US/ST=CA/L=Sunnyvale/O=Juniper Networks Inc./OU=SSL Inspection
        policy/CN=Juniper IT Services/
        issuer= /C=US/ST=CA/L=Sunnyvale/O=Juniper Networks Inc./OU=SSL Inspection
        policy/CN=Juniper IT Services/
        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-----
        -----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 Series device.
      3. Review logs to verify the feature operates as you expect.

    Published: 2011-02-08