Forum Discussion

Xavier_Gillmann's avatar
Xavier_Gillmann
Icon for Nimbostratus rankNimbostratus
Sep 09, 2005

(Client) SSL profiles config from iRules

Hi all,

First I have to say that this forum is really great: I found so many indications here... thank you everybody!! I hope this topic will contribute to this rich source of information...

I saw quite a lot of topics about control of SSL connections from iRules... one of which giving instructions to do more or less half of what I need to do: change SSL profile upon specific uri.


when HTTP_REQUEST {
  if { [HTTP::uri] eq "/manual/" } {
    SSL::cert mode require
    log LOCAL0.warn "Requiring certificate and Renegotiate..."
    log LOCAL0.warn "Set Authenticate always and depth 9..."
    SSL::authenticate always
    SSL::authenticate depth 9
    SSL::renegotiate
  } else {
    SSL::cert mode ignore
    log LOCAL0. "Other Pages"
  }
}

My first question is what about CRL file?

With the console, switching from "require" to "ignore" apparently "cleans up" the "crl file" entry in the clientssl profile (i.e. bigip.conf)... is this also the case when switching from iRules?

If not, how to 'start with' "ignore" as cert mode (i.e. for which I cannot set the CRL from the console) ? Is it enough to directly write in the bigip.conf something like:


profile clientssl xxx {
   defaults from clientssl
   key "xxx.key"
   cert "xxx.crt"
   ca file "xxx.crt"
   crl file "xxx.crl"
   peer cert mode ignore
}

My second question is not a 'pure iRules' one... I have 2 valid CA... As the client SSL profile " Trusted Certificate Authorities" is single-valued, I created one SSL Certificate bundle simply appending the 2 CA into one file. And it seems to work fine...

BUT both CA publish (HTTP) their CRL as (DER) files. So I'm planning to do the same as for certificates: converting DER files to PEM files... and append them into one (which would be the xxx.crl file here above).

I guess I need some OS-level scripting to do (and automate) that... and think about something like


!/bin/bash
wget /config/ssl/ssl.crl/firstCA.crl url_to_crl_file
openssl crl -inform DER -in firstCA.crl -outform PEM -out firstCA_PEM.crl
wget /config/ssl/ssl.crl/secondCA.crl url_to_crl_file
openssl crl -inform DER -in secondCA.crl -outform PEM -out secondCA_PEM.crl
cat firstCA_PEM.crl secondCA_PEM.crl > xxx.crl
openssl crl -in xxx.crl -text -noout

This little script would be scheduled (I don't know yet how!) every day.

The problem is: wget is not installed on my BigIP... neither a c compiler (to build wget binaries!).

I know I could install them... but I feel this would introduce security risks on the BigIP... and I feel it gets a bit dirty going deeper in this direction... So my question is: is there any other (simpler?) mean to do what I'm planning to do???

thanks in advance for the help,

Xavier

9 Replies

  • From the configuration guide under the writing irules section:

     

     

     

    Working with profiles

     

     

    When you are writing an iRule, you might want that iRule to know the value

     

    of a particular profile setting so that it can make a more-informed traffic

     

    management decision. Fortunately, the iRules feature includes a command

     

    that is specifically designed to read the value of profile settings that you

     

    specify within the iRule. Not only can iRules read the values of profile settings, but they can also override values for certain settings. This means that you can apply

     

    configuration values to individual connections that differ from the values the

     

    LTM system applies to most connections passing through a virtual server.

     

     

    Reading profile settings

     

     

    The iRules feature includes a command called PROFILE. When you

     

    specify the PROFILE command in an iRule and name a profile type and

     

    setting, the iRule reads the value of that particular profile setting. To do this,

     

    the iRule finds the named profile type that is assigned to the virtual server

     

    and reads the value of the setting that you specified in the PROFILE

     

    command sequence. The iRule can then use this information to manage

     

    traffic. For example, you can specify the command PROFILE::tcp idle_timeout

     

    within your iRule. The LTM system then finds the TCP profile that is

     

    assigned to the virtual server (for example, my_tcp) and queries for the

     

    value that you assigned to the Idle Timeout setting.

     

     

    Overriding profile settings

     

     

    You can use certain iRule commands to override specific profile settings.

     

    For example, you can use commands to override settings in an SSL or HTTP

     

    profile. When you specify these iRule commands, with setting values, then for the

     

    specific connection to which the iRule applies, the LTM system uses the

     

    setting values you specify in the iRule, rather than the values in the

     

    corresponding profile. iRule commands that override profile settings are:

     

     

    • SSL::renegotiate

     

    • SSL::cert mode

     

    • SSL::authenticate

     

    • SSL::authenticate depth

     

    • SSL::unclean shutdown

     

     

  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    Good point. I suppose you will need to do your suggested work around after all but just be careful that using the TMUI afterwards doesn't remove your changes.

     

     

    We did already file a CR for the TMUI removing the related fields if you change the cert mode to ignore (CR53737).

     

  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    Oh, BTW - you could try switching down in the CLIENT_ACCEPTED event. That event occurs at the completion of the 3-way TCP handshake before the SSL has even seen any packets.

     

  • I have to admit that I already tried that one too... but I got the following error message:

    
    [command is not valid in current event context (CLIENT_ACCEPTED)] [SSL::cert mode ignore]

    ... thank you for the CR: I'll follow that closely.

  • Can we using SSL::profile to solve this issue?

     

    the code may like this:

     

    when HTTP_REQUEST {

     

    if { [HTTP::uri] eq "/manual/" } {

     

    SSL::profile cert_require_profile

     

    SSL::renegotiate

     

    } else {

     

    SSL::cert mode ignore

     

    log LOCAL0. "Other Pages"

     

    }

     

    }

     

     

    with cert_require_profile, we can add CRL setting in it. so we can start with profile cert_ignor_profile that without CRL setting. if user access the "/menual/", then SSL::renegotiate will happen, when user submit client certificate, it will go through the CRL list.

     

     

    I will test it later. any good idea?
  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    The only issue with that approach is that the SSL::profile command isn't going to work under the HTTP_REQUEST event. The SSL::renegotiate command will, but you'll need to select which profile to use ahead of time.

     

     

    Colin
  • At last, I got this rules running:

    
    when CLIENT_ACCEPTED {
      set session_flag 0
     }
    when CLIENTSSL_HANDSHAKE {
      log LOCAL0.warn "cert count=[SSL::cert count]"
      if { [SSL::cert count] ==0 } {
        log LOCAL0.warn "when client handshake,ssl cert count is 0,pass"
      }
      else {
        log LOCAL0.warn "when clent handshake , two way cert founded and the cert count is [SSL::cert count] "
        HTTP::release
      }
      log "Session flag is $session_flag"
    }
    when HTTP_REQUEST {
      if {[HTTP::uri] starts_with "/manual/" } {
        log "Requiring certificate...and tht request uri is :[HTTP::uri]"
        if {[SSL::cert count] == 0} {
            log local0. "when http request,ssl cert count is 0,now http collect"
    HTTP::collect
        SSL::authenticate always
        SSL::authenticate depth 9
        SSL::cert mode require
        log local0. "when http request,now renegotiating"
        set session_flag 1
             SSL::renegotiate
        }
      }
      else {
        
        log LOCAL0.warn "No cert needed,to server directly.And the uri is [HTTP::uri]"
      }
      log "Session_flag at end of http_request is $session_flag"
    }

    with this rule, I can change the authenticate mode from ignore to require depends on the URI customer requie. But it can only running on BIGIP 9.1.2 and can't running on BIGIP 9.4.0 beta one build 211. BIGIP 9.4 seems can't caputure the client cert after renegotiate.
  • sure, Code share will save our time on it. and it's unique feature for BIGIP.

     

     

    I have informed that the CR for keep the Client certificate setting in client ssl profile will continue and you will see it in 9.4.

     

     

    Also, in 9.4, we can support CRLDP feature, so it's possible to add more CRLDP server in authentication profile.

     

     

    All these are good news, so waiting for 9.4 beta 2... The best is 9.4 final release.