Topic
  • 11 replies
  • Latest Post - ‏2019-08-14T17:39:40Z by PPotkay
PPotkay
PPotkay
222 Posts

Pinned topic DataPower as the SSL Client - Validation Credentials?

‏2018-02-07T23:39:32Z |

DataPower is the SSL Client, initiating the connection with the remote system that acts the role of the SSL Server.

In this scenario, the SSL Server are our Active Directory Domain Controllers. DataPower addresses them via a Load Balancer Group.

We want to use TLS 1.2 on this connection, to use LDAPS.

The SSL Server is not requiring mutual SSL Authentication, so this is "one-way" SSL.

We will build an SSL Client Profile to use on the Authentication and Credential Mapping tabs of the RBM settings.

 

In this scenario, what should the SSL Client (in this case DataPower) do for validating the SSL Server's certificates (in this case, the Active Directory servers)?

A. We could set "Validate server certificate" to Off on the SSL Client Profile

B. We could leave "Validate server certificate" as on, and create a Validation Credential that has only the signer cert(s) from the Certificate Authority that provided the SSL Server their certs. And set Certificate Validation Credentials to Full certificate chain checking (PKIX)

C. We could leave "Validate server certificate" as on, and create a Validation Credential that has the specific public cert(s) presented by the SSL Server. And set Certificate Validation Credentials to Match Exact Cert.


I'm not going with A - seems wrong to blindly accept any cert and not check it in any way.
So its a choice between B and C.

C means we would only complete the handshake if we matched up on the specific cert in our Validation Credential. Seems the most secure, but doesn't smell right. We are forever dependent on the SSL Server side to proactively tell us anytime they replace their cert. They have hundreds of systems coming to them. There is no way we can expect them to reliable tell us they are changing their certs.

So B seems like a good compromise. But then we are allowing the connection with any SSL cert signed by the Certificate Authority. That also seems wrong. When I act the role of SSL Client when surfing the web, when I hit a website at least the browser checks that the URL matches the cert provided. In MQ, we can use the SSLPEER parameter on the channel to match very specifically or broadly on fields in the cert. But DataPower seems to lack these features.

What is the correct thing to do as an SSL Client? Option B seems a little to loose, and Option C seems like a guaranteed outage in the future when the SSL Server side updates their cert for whatever reason and doesn't tell the 100s of SSL Clients. I don't blame them, if I am an SSL Server and using a CA signed cert, its not my job to baby sit every SSL Client coming to me forever after.

 

-Peter

  • ramkolla
    ramkolla
    131 Posts

    Re: DataPower as the SSL Client - Validation Credentials?

    ‏2018-02-08T16:34:18Z  

    Hi Peter,

    Option B (Full certificate chain(PKIX) doesn't allow any SSL cert signed by the CA but it allows only the SSL Cert you configure in your Validation Credentials object. It basically expects the AD server cert(also called leaf cert), intermediate cert(s) and the root cert to be present at SSL Client side for TLS Handshake to succeed.

    There's another Validation mode setting Match exact or immediate issuer, which does the acceptance of any SSL cert signed by the CA, in case you do not place AD server cert in your Validation Credentials.

    Coming back to your actual concern, I would either go with option B as it will have the entire chain of certs(AD server cert, intermediate cert(s), root cert) or go with option C.

    Both these cases mandate the presence of AD server cert in Validation Credentials, thus ensuring I'm validating the AD server.

    You problem of AD server incapable of conveying to its 100s of clients about it's cert expiry can be addressed by enabling Certificate Monitor on your DataPower appliances.

    We need to proactively reach out to AD support team to get the new cert and upload it to our ValCred object.

    Hope this helps!

    Thanks!

  • PPotkay
    PPotkay
    222 Posts

    Re: DataPower as the SSL Client - Validation Credentials?

    ‏2018-02-09T02:42:36Z  
    • ramkolla
    • ‏2018-02-08T16:34:18Z

    Hi Peter,

    Option B (Full certificate chain(PKIX) doesn't allow any SSL cert signed by the CA but it allows only the SSL Cert you configure in your Validation Credentials object. It basically expects the AD server cert(also called leaf cert), intermediate cert(s) and the root cert to be present at SSL Client side for TLS Handshake to succeed.

    There's another Validation mode setting Match exact or immediate issuer, which does the acceptance of any SSL cert signed by the CA, in case you do not place AD server cert in your Validation Credentials.

    Coming back to your actual concern, I would either go with option B as it will have the entire chain of certs(AD server cert, intermediate cert(s), root cert) or go with option C.

    Both these cases mandate the presence of AD server cert in Validation Credentials, thus ensuring I'm validating the AD server.

    You problem of AD server incapable of conveying to its 100s of clients about it's cert expiry can be addressed by enabling Certificate Monitor on your DataPower appliances.

    We need to proactively reach out to AD support team to get the new cert and upload it to our ValCred object.

    Hope this helps!

    Thanks!

    Thanks for replying ramkolla.

    I don't want to use Match exact certificate or immediate issuer, because the DataPower help for that topic says the following:

    The validation credentials contain either the exact peer certificate to match or the immediate issuer's certificate, which could be an intermediate CA or a root CA. This mode is maintained for backwards compatibility but Exact Match or PKIX are better choices in most cases.

     

    ramkolla wrote: "Option B (Full certificate chain(PKIX) doesn't allow any SSL cert signed by the CA but it allows only the SSL Cert you configure in your Validation Credentials object. It basically expects the AD server cert(also called leaf cert), intermediate cert(s) and the root cert to be present at SSL Client side for TLS Handshake to succeed."

    But the help for that topic says the following:

    "Full certificate chain checking (PKIX)
    The complete certificate chain is checked from subject to root when using the validation credentials for certificate validation. Validation succeeds only if the chain ends with a root certificate in the validation credentials. Non-root certificates in the validation credentials are used as untrusted intermediate certificates. Additional untrusted intermediate certificates are obtained dynamically from the context at hand (SSL handshake messages, PKCS#7 tokens, PKIPath tokens, and so forth).
    "

    That doesn't say the intermediate and/or leaf certificates need to be in the Validation Credentials. It quite specifically only calls out the root certificate being in the Validation Credentials.

     

    ramkolla wrote: You problem of AD server incapable of conveying to its 100s of clients about it's cert expiry can be addressed by enabling Certificate Monitor on your DataPower appliances.

    We need to proactively reach out to AD support team to get the new cert and upload it to our ValCred object.

    This cannot be relied on. You set your Certificate Monitor to alert when its x days out from Expiry. What if the SSL Server decides they replace certificates about to expire 1 day before x? Any number you set for your monitor has no hope of guaranteeing you will know they are about to replace the cert. And what if they decide to replace their cert for any reason other than pending expiration?

     

    I can't wrap my mind around having an SSL Client, in this case DataPower, gathering copies of public certs (from certs signed by a Certificate Authority you both trust!) to place in the trust store (on DataPower, the Validation Credentials). Why would I trust I got the right public cert when I manually get it, but I don't trust it on the actual SSL handshake?  Ignoring that inconvenient fact, it does not scale anyway. Its a guaranteed outage waiting to happen when the SSL Server updates their cert and doesn't tell you. There is no way its the responsibility of an SSL Server, using Certificate Authority signed certs, to have to hunt down every potential SSL Client that might call it in the future and ask them to please use a new copy of my public cert.

     

    There has to be a way for DataPower to know the public certificate presented by the SSL Server is a match for that specific SSL Server, without first gathering a copy of that public cert.. Web Browsers do it. MQ allows you to do it with the SSLPEER parameter. How does DataPower allow me to make sure I am taking to the correct SSL Server?

     

    -Peter

     

  • PPotkay
    PPotkay
    222 Posts

    Re: DataPower as the SSL Client - Validation Credentials?

    ‏2018-02-23T19:30:46Z  

    Could it be that DataPower doesn't validate the DNS Name it used to get to the SSL Server is present in the CN or SAN of the certificate presented by the SSL Server in the SSL handshake?

    Default domain

    DataPower is the SSL Client making an LDAPS call to the Active Directory Server that is the SSL Server.

    SSL Client Profile is used.

    Validate Server Certificate is On.

    A Validation Credentials object is referenced. The Val Cred has only the root signer cert from the Certificate Authority that provided the SSL Server their certs. And is set Certificate Validation Credentials to Full certificate chain checking (PKIX).

     

    Does DataPower validate the CN or SAN in the SSL Cert presented by the SSL Server match the hostname we sent to?

     

    We do not want to do exact match. Copying and maintaining public certificates in the Val Credentials objects seems like a endless maintenance contract that is doomed to fail anyway when the SSL Server does nothing wrong by updating its cert unannounced. We both use the same Certificate Authority, a major benefit being to avoid the nonsense of copying certificates.

     

    -Peter

  • ramkolla
    ramkolla
    131 Posts

    Re: DataPower as the SSL Client - Validation Credentials?

    ‏2018-02-27T16:18:19Z  

    What Peter is looking for is an interesting feature and would avoid manual update of certs.

    Can someone from DataPower Development team throw some light, if this is even possible at all?

     

    Thanks!

  • PPotkay
    PPotkay
    222 Posts

    Re: DataPower as the SSL Client - Validation Credentials?

    ‏2018-02-28T00:43:44Z  

    RFC 6125 Section B.3 says the below for LDAP. So, does an SSL Client Profile in the default domain do this mandatory checking? Copying certificates to manually place in the Validation Credentials is not a solution.

     

       3.6.  Server Identity Check

       The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's  Certificate message, in order to prevent man-in-the-middle attacks.

       Matching is performed according to these rules:

       o  The client MUST use the server hostname it used to open the LDAP

          connection as the value to compare against the server name as

          expressed in the server's certificate.  The client MUST NOT use

          the server's canonical DNS name or any other derived form of name.

       o  If a subjectAltName extension of type dNSName is present in the

          certificate, it SHOULD be used as the source of the server's

          identity.

       o  Matching is case-insensitive.

     

  • PPotkay
    PPotkay
    222 Posts

    Re: DataPower as the SSL Client - Validation Credentials?

    ‏2018-03-10T15:43:15Z  
    • PPotkay
    • ‏2018-02-28T00:43:44Z

    RFC 6125 Section B.3 says the below for LDAP. So, does an SSL Client Profile in the default domain do this mandatory checking? Copying certificates to manually place in the Validation Credentials is not a solution.

     

       3.6.  Server Identity Check

       The client MUST check its understanding of the server's hostname against the server's identity as presented in the server's  Certificate message, in order to prevent man-in-the-middle attacks.

       Matching is performed according to these rules:

       o  The client MUST use the server hostname it used to open the LDAP

          connection as the value to compare against the server name as

          expressed in the server's certificate.  The client MUST NOT use

          the server's canonical DNS name or any other derived form of name.

       o  If a subjectAltName extension of type dNSName is present in the

          certificate, it SHOULD be used as the source of the server's

          identity.

       o  Matching is case-insensitive.

     

    I provided the below info and packet captures to my PMR.

     

    DataPower Appliance A

    Is the SSL Client

    Firmware 7.5.2.11
    DNS Name = DPXI52A
    An MPG has its backside configured to go to https://dpxi2b.blabla.com:9999 (that is appliance B detailed below)
    SSL Client Profile is used
    In that SSL Client Profile: Use SNI is enabled / Use Custom SNI is not; Validate server certificate is on; A Validation Credentials object is used.
    In that Validation Credentials object: Cert Validation Mode is Full Certificate chain checking (PKIX); the root signer and intermediate signer certificates from our internal certificate authority are in the certificates of the Val Cred. The SSL Server's leaf certificate is specifically NOT in the Val Cred. 


    DataPower Appliance B
    Is the SSL Server
    Firmware 7.5.2.10
    DNS Name = DPXI52B
    An HTTPS Front Side Handler listening on port # 9999 is used, and it uses an SSL Server Profile
    In that SSL Server Profile, its Identification Credential object contains the private Key and certificate that was issued by our internal Certificate Authority. Intermediate CA Certificates is empty.


    We send a transaction from A to B while running a packet capture. 
    Frame #4 has the SSL Client Hello. In the SNI field you can see it has automatically populated dpxi2b.blabla.com.
    Frame#6 has the SSL Server Hello. In the certificates section you can see the certificate with a CN of dpxi2b.blabla.com.
    The SSL handshake continues normally over subsequent frames in this pcap.
    Working as expected. No problems here.


    We will now simulate a man-in-the-middle scenario.
    No changes are made to the SSL Client on DataPower Appliance A.
    On the SSL Server at DataPower Appliance B, we make one change. We remove the correct key/cert pair for dpxi2b.blabla.com (which was provided by our Certificate Authority) and replace it with another cert/key pair provided by our certificate authority. This new cert/key pair is valid, not expired, not revoked, signed by our CA. 
    Everything is correct, except its CN is not for dpxi2b.blabla.com. It is for another address. Its CN has someothersite.blabla.com. 
    The Identification Credentials for DPXI52B has been purposely configured to present the wrong certificate for dpxi2b.blabla.com. It will present a cert with a CN for some other address. Any SSL Client should not accept this. As an SSL Client they went to dpxi2b.blabla.com, but the SSL Server is presenting a certificate for some other address called someothersite.blabla.com. 

    Let's do a packet capture again.
    Frame #4 has the SSL Client Hello. In the SNI field you can see it has automatically populated dpxi2b.blabla.com.
    Frame#6 has the SSL Server Hello. In the certificates section you can see the certificate with a CN of someothersite.blabla.com.
    The SSL Handshake continues in subsequent frames as if nothing is wrong!

    The DataPower SSL Client has simply ignored what can be seen as a man-in-the-middle attack. It reached out to one address (dpxi2b.blabla.com) and whatever responded presented a certificate for some other address, yet the DataPower SSL Client just keeps on going. The DataPower SSL Client clearly knows where it is going, as evidenced by the SNI value it automatically filled in on the SSL Client Hello. It got something else, and accepted it without even a warning.

    Yes, if at the SSL Client we place the exact certificate for the legitimate dpxi2b.blabla.com and did "Exact Match", the SSL Handshake with the incorrect certificate would have failed. But this is not the correct solution where both SSL Client and SSL Server use and trust the same Certificate Authority. It does not scale and is likely to mean an outage when the SSL Server does nothing wrong by updating its certificate without notifying and waiting for all its clients to copy the new cert.

    I believe it is a defect that DataPower as an SSL Client accepts a certificate from an SSL Server that does not match the address used by the SSL Client.

     

    -Peter

  • PPotkay
    PPotkay
    222 Posts

    Re: DataPower as the SSL Client - Validation Credentials?

    ‏2018-03-28T11:28:10Z  

    My PMR continues, but I fear its a losing battle. Currently the PMR stands as IBM DataPower CAN validate the SSL Certificate presented by SSL Server is for the intended SSL Server you addressed - just put a copy of the public cert into the Val Cred.

    Yes, OK, that will work. But is that working as designed with a poor design, or do I have a case for a defect?

    I fear this is heading towards the PMR being closed as "Works as designs; open an RFE" which means it will be years before its fixed, if ever.

     

    So keeping this thread alive hoping people can give me additional advice/ suggestions for the PMR before its closed.

    When both SSL Server and SSL Client use and trust the same Certificate Authority, does it make any sense that certificates have to be copied between systems to make it work properly? Is that not a defect? It completely flies in the face of the main reason you switch off of Self Signed certificates and start using a PKI. I feel DataPower does not properly support a PKI environment if by design it requires us to copy certificates between systems. 

     

    Peter

    Updated on 2018-03-28T11:32:06Z at 2018-03-28T11:32:06Z by PPotkay
  • rk1891
    rk1891
    5 Posts

    Re: DataPower as the SSL Client - Validation Credentials?

    ‏2018-09-13T13:38:10Z  
    • PPotkay
    • ‏2018-03-28T11:28:10Z

    My PMR continues, but I fear its a losing battle. Currently the PMR stands as IBM DataPower CAN validate the SSL Certificate presented by SSL Server is for the intended SSL Server you addressed - just put a copy of the public cert into the Val Cred.

    Yes, OK, that will work. But is that working as designed with a poor design, or do I have a case for a defect?

    I fear this is heading towards the PMR being closed as "Works as designs; open an RFE" which means it will be years before its fixed, if ever.

     

    So keeping this thread alive hoping people can give me additional advice/ suggestions for the PMR before its closed.

    When both SSL Server and SSL Client use and trust the same Certificate Authority, does it make any sense that certificates have to be copied between systems to make it work properly? Is that not a defect? It completely flies in the face of the main reason you switch off of Self Signed certificates and start using a PKI. I feel DataPower does not properly support a PKI environment if by design it requires us to copy certificates between systems. 

     

    Peter

    Based on my experience DataPower does not do a URL integrity check. That's what you are probably looking for. I don't remember where I read but thought it is an optional check in terms of SSL semantics.

     

    I come across this issue few years ago where we use DataPower both as a  Server and client and we also deal with 100+ customers.  When we are acting as a server we also do client cert authentication. In both cases we ended up using CA certs only to validate our customers so not to bother to install each individual customers' certs into Datapower.

     

    When Datapower acts as a server and doing client cert authentication, it does write certain information into variables like dp:client-subject-dn() and dp:client-issuer-dn(). We have used this information to validate against a configuration file either tied to their WS-Security username or Client IP address.

    I kind of hoped that Datapower can do something on same lines when it is acting as a client. Saw few posts on here about that but not sure if an enhancement request is open in that regard or you could steer the PMR in to that direction.

     

     

  • PPotkay
    PPotkay
    222 Posts

    Re: DataPower as the SSL Client - Validation Credentials?

    ‏2018-09-13T13:47:17Z  

    My PMR continued until May. It ended with the following:

     

    Hello Peter!

     Good news!

    The architects of the product have reply:

     

    "We listened to your concerns and that we will deliver this requirement to ensure smooth and secure operations of their DataPower Gateway environment.

    We are targeting this feature for 3Q 2018, but plan delivery is subject to change based on business demands.""

  • samik chakraborty
    samik chakraborty
    1 Post

    Re: DataPower as the SSL Client - Validation Credentials?

    ‏2019-07-01T16:17:56Z  
    • PPotkay
    • ‏2018-09-13T13:47:17Z

    My PMR continued until May. It ended with the following:

     

    Hello Peter!

     Good news!

    The architects of the product have reply:

     

    "We listened to your concerns and that we will deliver this requirement to ensure smooth and secure operations of their DataPower Gateway environment.

    We are targeting this feature for 3Q 2018, but plan delivery is subject to change based on business demands.""

    Hi IBM Team,

     

    I have observed in IDG 2018.4.1.4 , If 'Host name validation fail on error' set to on then the valcred option disappears in ssl client profile. What happens to certificate validation if the hostname validation is success with the above as on? Will datapower not validate server certificates in this case?

  • PPotkay
    PPotkay
    222 Posts

    Re: DataPower as the SSL Client - Validation Credentials?

    ‏2019-08-14T17:39:40Z  

    Finally got around to reviewing to Whats New in 2018.4.

    Happy to say IBM implemented SSL Server Host name checking for the Validation Credential object.

    https://www.ibm.com/support/knowledgecenter/en/SS9H2Y_7.7.0/com.ibm.dp.doc/whats_new20184.html#whats_new20184__sslclient

     

    A big step in the right direction.

    I hope additional fields in the Validation Credentials object in the future will allow us to filter connections based on the various fields in the CN of the SSL Cert the SSL partner presents. This will finally allow us to stop pinning to specific copies of SSL partner certs - a pattern that does not scale.

     

    Peter