Question

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?
Was it helpful?

Solution

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.

OTHER TIPS

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.

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.

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.

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).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top