| Author |
Message
|
| zhanghz |
 Posted: Thu May 07, 2009 5:49 pm Post subject: NULL_MD5 means no encryption on the messages? and other Qs.. |
 |
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
Simple questions, I guess, but I am just a little bit confused.
Questions are, when I use NULL_MD5 as the SSLCIPH,
1) MQ only hashes the message content but does not encrypt it?
2) Will a "secret key" still be generated during SSL handshake upon channel starting?
3) During SSL handshake, MQ will verify the SSL cert received. To verify the cert, MQ will check the validity period and DN of the cert received, and also decrypt using public key. How does MQ know what encyption/decryption method to use here?
Thanks. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu May 07, 2009 5:58 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Don't use MD5
https://listserv.meduniwien.ac.at/cgi-bin/wa?A2=ind0904&L=mqser-l&T=0&F=&S=&P=1620
| Quote: |
The attack is more general than that - given any certificate which uses the MD5 hash algorithm for signing they can create a certificate body containing a public key to which they have the private key and an arbitrary set of capabilities. The highest-value such certificate they can generate is a certificate which says it is intended for use as a CA certificate, which is why they chose to demonstrate that. Their technique can equally well generate server or client certificates.
To protect your systems you need to know that no CA you trust has issued any certificate which relied on MD5 for its signing. That's a pretty-strong statement, and one I suspect most CAs cannot make. In time, SSL stacks will probably change to reject any MD-5 signed certificates, but for now that is not the case. Note that CRLs (and OCSP) are no help here as the certificate ID (or OCSP URL) they check is part of the signed data in the certificate and can therefore now be spoofed.
Now is probably also a good time to ensure you are using a CipherSpec which does not include MD5 (e.g. TLS_RSA_WITH_AES_256_CBC_SHA which is my personal favourite at the moment). The cipher-spec in SSL does not cover how the certificates are verified, so this alone will not protect from the certificate-forging attack.
Note that FIPS has disallowed MD5 for some time: there have been indications that MD5 is weak to collisions for some years; this attack was expected rather than a surprise.
It's interesting stuff. The attack currently takes about 2 weeks on a mid-sized supercomputer, but if similar historical incidents are anything to go by further research and computing improvements are likely to bring that down to the point where an on-line attack during SSL negotiation is viable.
Regards,
Phil Willoughby
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zhanghz |
| Posted: Thu May 07, 2009 7:43 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
thanks peter, that's good to know.. but anyway it's not a concern for me.
I am still looking forward to hearing answers to my questions.  |
|
| Back to top |
|
|
| zhanghz |
| Posted: Sun May 10, 2009 4:25 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
| Hi guys, can anyone advise? Thanks. |
|
| Back to top |
|
|
| ranganathan |
| Posted: Mon May 11, 2009 6:07 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2008
Posts: 104
|
I guess...
since both ends of SSL channel definition must include the attribute (if specified at one end) and must specify the same CipherSpec, Through SSLCIPH MQ identifies the encryption/decryption method (if used). along with SSLPEER attribute to check Distinguished Name (DN) of the certificate..
Last edited by ranganathan on Mon May 11, 2009 6:17 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 11, 2009 6:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Using NULL_* means that only the session handshake is encrypted.
Certificates are encrypted and signed using different algorithms than the ones in use over an SSL session. I believe the certificate format indicates the algorithms used, but I could be remembering wrong.
I don't believe that a session key will be created for an unencrypted session. |
|
| Back to top |
|
|
| zhanghz |
| Posted: Mon May 11, 2009 5:28 pm Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
Thanks jeff, confirmed my understanding regarding my questions 1 and 2.
I went throught chapter 4 and 16 of MQ Security V6 several times. Regarding my question 3, the anwser seems to be "RSA key exchange and authentication algorithm".
| Quote: |
| The key exchange and authentication algorithm, used during the SSL handshake |
| Quote: |
| WebSphere MQ supports only the RSA key exchange and authentication algorithms. The size of the key used during the SSL handshake can depend on the digital certificate you use, but some of the CipherSpecs supported by WebSphere MQ include a specification of the handshake key size. |
Thanks all. |
|
| Back to top |
|
|
|
|
