Forum Discussion

Victor_126772's avatar
Victor_126772
Icon for Nimbostratus rankNimbostratus
Jun 25, 2013

Middleware

 

Faced with an interesting challenge to fully encrypt transport of Wingspan data from consumer -> service and service -> consumer. Tibco Policy Director allows creation of authentication policies to encrypt traffic once received by the service. This presents a red flag since FRB policies require data to be encrypted while in flight and at rest.

 

 

An interim solution is to create public key certs and provide these unique keys to consumers of the service. The service has a private key that decrypts the data once received. This covers transport from consumer to service. As you are aware, this is not the best method given the number of certs ultimately managed by Wingspan over time.

 

 

Currently reviewing a Tibco product, Active Matrix Gateway (AMX) which may facilitate this requirement. Nonetheless, requisition of the product and implementation once received may take a considerable amount of time to turn around.

 

 

Please provide info on f5 capabilities in regard to off-box SSL. I recall an implementation where this option provided a wild card cert to fully encrypt data.

 

 

Appreciate your continued support.

 

1 Reply

  • Client side (client to F5) and server side (F5 to server) are separate profiles attached to the virtual server, and work independently of one another. You can decrypt SSL on the client side and not re-encrypt to the server, not encrypt on the client and encrypt on the server side, decrypt and re-encrypt, and not decrypt or re-encrypt at all (SSL bridging mode). You can also do SSL "man-in-the-middle" with version 11.x. The profiles also allow you some pretty dynamic control over the SSL. On the client side for example, you can set a standard server certificate to handle one host, a wildcard or SAN (subject alt name) cert that be used will all or some hostnames, or you can even do SNI (server name indicator), a TLS extension that allows you to apply multiple single host client SSL profiles to a VIP that will be used based on the client's request.

     

     

    Each of these options are fairly easy to configure via management GUI, console shell, or remote API. You could very simply apply a wildcard cert to a client SSL profile and not have to worry about future modifications, or if that is too expensive an option, you can do SNI and dynamically and programmatically import server certificates, create single host SSL profiles, and then assign them to the VIP(s) to do SNI.