cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3983
Views
0
Helpful
12
Replies

Encrypt or not ? ODBC connection to MSSQL in ISE

tuenoerg
Cisco Employee
Cisco Employee

Hi all,

 

We have a customer that is asking about the ISE ODBC connection to MSSQL.

 

According to our documentation we only support SQL server authentication - but no technical details.

Reading through MS documentation - it should be encrypted.

https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/authentication-in-sql-server#mixed-mode-authentication

https://docs.microsoft.com/en-us/sql/relational-databases/security/choose-an-authentication-mode?view=sql-server-2017#connecting-through-sql-server-authentication

 

But it seems that there is an old downgrade attack that forces auth to be done on plain text.

https://f0rki.at/microsoft-sql-server-downgrade-attack.html

 

So questions I need answer for are:

Are we using ENCRYPT_NOT_SUP pr default in ISE (aka unencrypted password exchange)?

Would we allow the downgrade attack or ?

Can we force ENCRYPT_REQ to make sure we encrypt all data - including password exchange?

 

Br

Tue Frei Noergaard

1 Accepted Solution

Accepted Solutions

Surendra
Cisco Employee
Cisco Employee
We do encrypt the entire connection using SSL and we force the encryption to happen by setting a parameter named "encrypt" to true as per the documentation https://docs.microsoft.com/en-us/sql/connect/jdbc/setting-the-connection-properties?view=sql-server-2017

Both cases “Plain text password authentication in ODBC DB” and “Plain text password fetching from ODBC DB”. ISE provides the security enhancement to close this vulnerability by allowing configuring secure ODBC connection between ISE and the ODBC DB. First the secure connection SSL tunnel is established and then all the data including username and password for both cases from above comes encrypted inside the tunnel and
thus inaccessible for attacker.

Please feel free to drop a mail if you need the source of information.

View solution in original post

12 Replies 12

Surendra
Cisco Employee
Cisco Employee
We do encrypt the entire connection using SSL and we force the encryption to happen by setting a parameter named "encrypt" to true as per the documentation https://docs.microsoft.com/en-us/sql/connect/jdbc/setting-the-connection-properties?view=sql-server-2017

Both cases “Plain text password authentication in ODBC DB” and “Plain text password fetching from ODBC DB”. ISE provides the security enhancement to close this vulnerability by allowing configuring secure ODBC connection between ISE and the ODBC DB. First the secure connection SSL tunnel is established and then all the data including username and password for both cases from above comes encrypted inside the tunnel and
thus inaccessible for attacker.

Please feel free to drop a mail if you need the source of information.

Thank you Surendra.

 

-Krishnan

Hi Surendra,

I am the guy that was asking Tue about this, and i have my customer the information you provided, thanks you for that. The Customer has some further questions into this, maybe you are able to answer them ?

---

According to the documentation and your statement, Cisco ISE is using the JDBC encrypt property set to true. That's good news, but without further information this raises a few concerns.

According to the JDBC documentation [1], using encrypt=true only enables encryption if the server specifies a certificate. This would signify that ISE does not *require* encryption but merely request it, and thus is still vulnerable to the aforementioned vulnerability. Are there any supplemental properties set to enforce encryption?

Both the encrypt property and the new authentication property since JDBC version 6 does not document whether or how it's possible to enforce and require authentication. Rather, it looks like both properties merely *request* encryption, still leaving Cisco ISE open to the attack.

Also, how is the server certificate verified, and what CA is used? This should be specified through trustServerCertificate, hostNameInCertificate and trustStore which are set to unknown values or defaults in ISE - and definitely not documented.


In summary:

* Is it possible to specify which CA certificates in the ISE Trust Store can be used for verifying the MSSQL server certificate?
* Is it possible to specify which SubjectName is permitted in the certificate, or is it set automatically based on another parameter?
* Is it possible to specify encryption is to be *required* and not merely *requested*?

Hi Surendra,

I got this from the consultant handling the customer. Can you help us again?

 

"

I am the guy that was asking Tue about this, and i have my customer the information you provided, thanks you for that. The Customer has some further questions into this, maybe you are able to answer them ?

---

According to the documentation and your statement, Cisco ISE is using the JDBC encrypt property set to true. That's good news, but without further information this raises a few concerns.

According to the JDBC documentation [1], using encrypt=true only enables encryption if the server specifies a certificate. This would signify that ISE does not *require* encryption but merely request it, and thus is still vulnerable to the aforementioned vulnerability. Are there any supplemental properties set to enforce encryption?

Both the encrypt property and the new authentication property since JDBC version 6 does not document whether or how it's possible to enforce and require authentication. Rather, it looks like both properties merely *request* encryption, still leaving Cisco ISE open to the attack.

Also, how is the server certificate verified, and what CA is used? This should be specified through trustServerCertificate, hostNameInCertificate and trustStore which are set to unknown values or defaults in ISE - and definitely not documented.


In summary:

* Is it possible to specify which CA certificates in the ISE Trust Store can be used for verifying the MSSQL server certificate?
* Is it possible to specify which SubjectName is permitted in the certificate, or is it set automatically based on another parameter?
* Is it possible to specify encryption is to be *required* and not merely *requested*?

"

Best regards

Tue

Answering your questions in order.

1. No, it is not possible to choose a specific CA certificate. ISE will validate aganist all the certs in the store.
2. Can you explain more ? Which certificate are we talking about ?
3. No. Currently ISE does not support enforcement of trust. There is an internal enhancement request open for this.


@Surendra wrote:
Answering your questions in order.

1. No, it is not possible to choose a specific CA certificate. ISE will validate aganist all the certs in the store.
2. Can you explain more ? Which certificate are we talking about ?
Since we can't decide what certs to trust on a per-certificate basis be only on a trusted CA basis, it would be nice if ISE only accepted the servers certificate if it contained a certain CN, or if the CN had to match the configured server fqdn in the ODBC configuration of ISE,
3. No. Currently ISE does not support enforcement of trust. There is an internal enhancement request open for this.
Great, is it possible to share that information with the local SE so we might track that enhancement request?

 

Futures aren’t discuss in public forum please reach out to us via http://cs.co/ise-feedback

Understood, i will let my local SE figure out how to keep us informed.

please share enhancement bug id with me on internal email : tuenoerg@cisco.com

So, could you shed some light on question 2?

2. Can you explain more ? Which certificate are we talking about ?

This would be the SQL server certificate we need to validate as a SQL client in ISE. Does ISE accept *any* certificate CN/subject name as long as the cert is signed by an approved CA? Or does ISE check the certificate CN against eg. the ODBC connection server name entered in ISE?

As long as ISE trusts it, it will accept that certificate. As of now, there is no provision to choose one.

ok, thanks for the reply