1

We are in the process of certifying our health care product (Hitech certification). One of the criteria of the certification process is that our product should be capable of using "hashing" when sending patient information over the network. Our product is a thick client that connects directly to Sql Server 2005 database. So when we send patient information from client to DB store procedure, it should use "hashing" to make sure that the information wasn't altered in transit.

Now, we are planning to connect our client to the Sql Server using SSL secure connection. When I read about SSL protocol, it seems like SSL uses hashing internally. So if thats true, I could automatically satisfy the hashing requirement by using SSL connection between client and sql svr.

So here are my Questions

  • When data is transmitted over an SSL connection, is each message attached with a hash internally, such that the SSL protocol verifies that data hasnt been modified?
  • Does SSL use the hashing mechanism only during the initial steps of its handshake? So after the handshake is complete, it only encrypts/decrypts data without any hashing mechanism involved?
  • If SSL does attach a hash for each message, is the "public key" used to create the hash?
Hogan
  • 63,843
  • 10
  • 75
  • 106
FatherFigure
  • 1,097
  • 1
  • 14
  • 37

5 Answers5

2

Even if SSL uses hashing, that will only ensure the part of the transmission that SSL handles. There is still a gap at either end between the client application and the network connection, and between the network connection and the server application.

You need to create a hash of the data that travels with the data all the way from inside the client application to inside the server application.

Guffa
  • 640,220
  • 96
  • 678
  • 956
  • Doesn't the OP say he is doing an SSL connection from the client application to SQL? Sounds like these "points" are a non-issue. – Hogan Nov 02 '10 at 17:41
  • @Hogan: If I ordered the application, I would certainly see it as an issue if it could not verify that the data is not altered. There are other things than just the plain data transfer that can go wrong. – Guffa Nov 02 '10 at 17:49
  • @Guffa : Sure, but a certification does not have just one item. I'm sure there are other requirements concerning risk at the endpoints. – Hogan Nov 02 '10 at 17:51
  • 1
    @Guffa. Lets' assume its a C# Windows app. And a SQL Connection is opened using "Use Encryption for Data=True". And a SQL Statement is issued, I'm confused about where the gap could possibly be? – Conrad Frix Nov 02 '10 at 17:59
  • 1
    @Conrad Frix: You still have to be able to verify that the values that you send to the query are not altered or truncated by the query. The encryption doesn't protect from that in any way. – Guffa Nov 02 '10 at 18:16
  • @Guffa. So the suggestion is that every query would need to use some sort of tapering function, because the parameters could be modified prior to execution of the query, via a debugger for example. That attack vector is probably not considered often enough on thick clients. – Conrad Frix Nov 02 '10 at 18:35
  • @Guffa Wait what. I call sp_set_foo "bar" there's a concern that only "b" got recorded and its not the result of something malicious? – Conrad Frix Nov 02 '10 at 19:47
  • 1
    @Conrad Frix: Yes, basically. Field length shouldn't fail silently, but things like character encoding and number precision will. – Guffa Nov 02 '10 at 20:45
2

It depends. The two negotiating parties can negotiate the level of protection and the algorithms used. The most common case is that the negotiation uses TLS, not SSL, message privacy is requested (ie. encryption) and tampering protection is requested (ie. signing). TLS uses per message hashing based on HMAC, see chapter 5 of RFC2246. SSL uses a MAC, which is slightly weaker than an HMAC (an MAC does not contain a secret in its digest).

At a 10000 ft executive level view the answer is 'Yes, SSL hashes each message'. Enforcing SSL encryption on the SQL Server client protocol is usualy required in compliant deployments. For more details and guidance check the webcast and white papers at SQL Server Compliance.

Remus Rusanu
  • 273,340
  • 38
  • 408
  • 539
  • This all seems a non-issue. The point of the requirement is that PII is not sent in the clear. Seems SSL will always satisfy that, right? – Hogan Nov 02 '10 at 17:42
1

SSL is stronger than hashing. It should satisfy your requirement.

I will be clearer:

SSL encrypts all data that is transmitted. This means that the data can not be read and if it is changed it can not be decrypted. SSL thus prevents you from eaves droppers and from changes.

The requirement was written with an expectation that most communication was done in the clear. With the use of SSL you easily satisfy this requirement.

Important Note: Make sure you SSL communication is correctly implemented -- it is the single point of failure.

Hogan
  • 63,843
  • 10
  • 75
  • 106
  • Note: certifications are more about the letter of the requirements than the spirit of the requirements, so the OP probably needs verification that specific hashing and verification steps are being taken at the specified steps in the protocol. – jball Nov 02 '10 at 17:31
  • @jball : read my additional comments. I can't imagine the OP will baulk at SSL being used. Every certification I've ever gone through has been about satisfying or exceeding the requirements -- you will do that with SSL – Hogan Nov 02 '10 at 17:33
  • 1
    @Hogan, as long as the requirements in the certification specify "or exceed" or something similar, your answer is correct. I've just run into too many red tape "must have `x`" requirements to feel safe assuming that. – jball Nov 02 '10 at 17:47
  • @jball : ok look here http://en.wikipedia.org/wiki/Secure_Sockets_Layer#How_it_works as I read it MD5 is being used on all communication. – Hogan Nov 02 '10 at 17:57
  • @jball : Also, I've never worked on a certification where exceeding the requirements did not satisfy them. – Hogan Nov 02 '10 at 18:02
  • You haven't really answered the question here. Encryption does not *ipso facto* guarantee that the data cannot be decrypted if changed. That requires specific encryption techniques, and where required is generally accompanied by a MAC or better still a digital signature. – user207421 Nov 04 '10 at 12:16
  • @EJP : Your statement may be true in the general case, but it is not true in the specific case, SSL does guarantee this, if it didn't then SLL would not be secure. – Hogan Nov 04 '10 at 14:04
  • SSL is secure from data changes *because it computes an HMAC.* Not just because it encrypts, which is what you said. – user207421 Nov 05 '10 at 02:42
1

SSL, or TLS (you're likely to be able to use TLSv1.0 at least nowadays, even when talking about "SSL"), aims to protect aims "[...] to provide privacy and data integrity between two communicating applications" (see RFC).

RFC 4346 goes on saying:

The TLS Record Protocol provides connection security that has two basic properties:

  • The connection is private. [...]
  • The connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations. The Record Protocol can operate without a MAC, but is generally only used in this mode while another protocol is using the Record Protocol as a transport for negotiating security parameters.

So, yes, it will detect attempts to corrupt the data transmission (intentional or accidental).

Bruno
  • 110,518
  • 24
  • 258
  • 357
1

When data is transmitted over an SSL connection, is each message attached with a hash internally, such that the SSL protocol verifies that data hasnt been modified?

Yes. It appends a keyed MAC to each TLS record exchanged.

Does SSL use the hashing mechanism only during the initial steps of its handshake?

No, it occurs throughout.

If SSL does attach a hash for each message, is the "public key" used to create the hash?

No. A shared secret is used to create the hash.

See RFC2246 for details.

user207421
  • 289,834
  • 37
  • 266
  • 440