Firefox, openssl, ipv6 and certificates
Running into an odd problem with ipv6 self signed certificates. Firefox does not seem to be able to or want to accept them. Same certificate is ok on ipv4. What attributes are normally found in a certificate for ipv6..does anybody have an example they could share with me? Anybody run into the firefox thing? Thank you, Mike
OpenSSL & "Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542)"
Security Update for Windows Server 2008 R2 x 64 Edition (KB2585542) http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28629 Does anybody have any experience with this security patch? It seems to affect older versions of openssl (0.9.7 or so)... does anybody have experience with newer versions? [Basically after the patch is added..older openssl versions can't maintain a connection] Thank you, -Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
Dave, I think I have been getting ahead of myself and need to do some more reading. More quick questions, if you don't mind me asking. I have included an answer you gave me months ago regarding Yc. For a 192bit curve, the number of bytes is 50. I imagine one of the bytes is if the point is compressed or uncompressed. (Is that right?) What is the length prefix? Is that what is referred to as PublicValueEncoding in RFC4492? Where can I read about that and how it is set? Thanks for your help, I really appreciate it. Mike First, a caveat: I set up a test to verify my understanding, and found (to my surprise) that s_server at least doesn't try to use the same curve for kECDHE as for aECDSA; it's a separate choice, and defaults to sectp163r2. Are you sure either your server or your client is selecting (forcing) prime192r1 for keyagreement AS WELL AS signing/authentication? That said, I get *49* bytes of ECDH data (Yc), plus a 1-byte length prefix totalling 50, in a ClientKeyExchange message totalling 54, in a (clear) handshake record totalling 59. Combined with other records/messages into a TCP segment etc. If that's not what you got, you did something different. --- On Mon, 1/11/10, Dave Thompson wrote: > From: Dave Thompson > Subject: RE: trying to understand ECDHE operations > To: openssl-users@openssl.org > Date: Monday, January 11, 2010, 5:48 PM > > From: owner-openssl-us...@openssl.org > On Behalf Of Michael D > > Sent: Friday, 08 January, 2010 08:53 > > > Based on the old message snippet below, two > questions: > > 1) Are the session keys then used by the symmetric > cipher > > going forward? > > Or is there another step used to get those keys. > > > Session keys are for symmetric data cipher AND data HMAC. > (TLS actually calls the HMAC secret parameter "secret" > although RFC 2104 and IME most other usage calls it > "key".) > > > For example, if I am using 192 bit ECC, and using > AES-128, what do > > I use for the 128 bit key? > > > Two specified 128bit chunks of TLSPRF(master,otherstuff) > where master = TLSPRF(premaster,otherstuff). > > See RFC 4346 8.1 and 6.3 (and 5) as modified by 4492 5.10. > > > If I used AES 256, would I need a larger number of > bits in > > the ECC curve? > > > You don't NEED it. TLS key derivation generates enough > key material, regardless of the size of premaster. > However, premaster must contain enough entropy to support > the desired security; per Kerckhoff (sp?) everything else > is knowable by the attacker. > > 128bit symmetric is plenty for many years; like Schneier's > > "stake" it's stronger than the rest of your system. > So AES256 versus 128 should only be needed for interop > and/or > buzzword compliance -- which can be useful, and (here) > doesn't > hurt. If you really want 128bit or more security level, > you do need to use for keyagreement an EC curve big enough > > to provide that security level. According to NIST in SP > 800-57, > EC of 2N bits is roughly equivalent to symmetric of N bits, > > so even for "full" AES128 you should be using EC>=256. > But you may find other experts with different judgements. > > And you must also have enough "good" random-data generation > > involved (in ECDHE transients, or as noted static-ECDH > nonces). > I believe in practice this has more often been a weakness > (and successful attack) than actual cryptography. But it's > > harder to analyze and basically impossible to prove. > > > > > 2) The last part of the Where can I read about how SSL > makes session > > unique with a nonce, how is that done and or where can > I read > > about it? > > > Much of RFC 4346. > > > > > Static aka fixed ECDH (or DH) does use the > certified key as > > > the > > > server part of keyagreement. Client similarly if > client > > > auth > > > i.e. cert is used, which it usually isn't; but > even though > > > that > > > gives a fixed (EC)DH result, SSL still makes the > > > sessionkeys > > > unique by adding per-session/handshake nonces. > > > > > > __ > OpenSSL Project > > http://www.openssl.org > User Support Mailing List > openssl-users@openssl.org > Automated List Manager > > majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Parse the ECC server key exchange?
I am trying to understand the server key exchange message.
It would be nice if I could compare and understand an actual
packet while looking at RFC 4492.
I am using openssl s_server and s_client for my experimenting.
There is a lot of stuff in that message.
struct {
ECParameterscurve_params;
ECPoint public;
} ServerECDHParams;
Being able to recognize something like the ECPoint would be a help
to understand it.
Thanks,
Mike
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
Hello, As always, I appreciate all the help. Based on the old message snippet below, two questions: 1) Are the session keys then used by the symmetric cipher going forward? Or is there another step used to get those keys. For example, if I am using 192 bit ECC, and using AES-128, what do I use for the 128 bit key? If I used AES 256, would I need a larger number of bits in the ECC curve? 2) The last part of the Where can I read about how SSL makes session unique with a nonce, how is that done and or where can I read about it? Thank you, Mike > Static aka fixed ECDH (or DH) does use the certified key as > the > server part of keyagreement. Client similarly if client > auth > i.e. cert is used, which it usually isn't; but even though > that > gives a fixed (EC)DH result, SSL still makes the > sessionkeys > unique by adding per-session/handshake nonces. > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
back trying to understand ECDHE
Hello, Once again I back trying to understand ECDHE. I would like to use openssl and s_server and s_client for my trail and error testing. I have my notes on generating a key file, but I can't seem to find my notes on starting s_client and s_server such that they do the elliptic curve diffie helman negoications. If anybody can throw command lines my way, I would sincerely appreciate it. Thank you, Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Secure command line "enc -K"
Is there a way to securely pass an exact key to "openssl enc"? The "-pass" option is looking for a password that it will pass though a key derivation function (IIUC), but I want to specify the exact binary key to use without it being passed though a key derivation function. The "-K" option would fit my needs, except that since it requires the key to be put on the literal command line, it exposes the key to other users on the same system (they can run "ps -f"). I'm looking for something like "-pass file:" (to keep the key off the command line) except I want to bypass the key derivation function. (If I were hashing instead of encoding I would just use "openssl sha1 -sign hmac.pem".) Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu, Oct 1, 2009 at 4:37 PM, Kyle Hamilton wrote: > The question becomes more one of: Why does the OP need to keep the > HMAC computation key secret? Is the OP using the same key for HMAC > calculation as for symmetric encryption? (If so, why? If not, why > does the OP need to keep the verification key secret?) I'm not using the same key for HMAC as for symmetric encryption. It was my understanding that the HMAC key needed to be secret even when used for verification. (Otherwise people could forge an HMAC.) But you ask a fair question (i.e. Why keep the key secret?) and I'll try to answer. I'm not using an HMAC for message authentication, but for a more indirect purpose. (I apologize in advance for the length, explaining "why" requires a little context.) I am working with a backup system where the files are stored and referenced by their hash (similar to how git stores it's data). I would like to make it be able to store those files in encrypted form. In order for this system to work, we want two different encryptions of the same file with the same key to produce the exact same result. This rules out using a random initialization vector (IV). With the exception of SIV (which isn't yet widely implemented), my understanding is that reusing an IV for two different messages opens up avenues of crypto-analytical attack. Thus we want to use a different IV for each file, but use the same IV when the file contents are the same (*). The obvious choice is to use a cryptographic hash of the file's contents as the IV. It will be the same when the file contents are the same, but different when the file contents are different. Now that works great except for one thing. For simplicity of implementation, we would like to store that calculated IV in clear text as a header at the front of the encrypted file and then just use one of the block-cipher modes that remains secure even when the IV is known to the attacker. However, storing the IV in the clear opens up a dictionary attack if the attacker can easily compute the hash used to compute the IV (**). To get around this, I was planning on using a secret key with an HMAC (so the attacker couldn't compute his own hashes), but passing that key on the command leaks that secret key. To summarize: I would have done this: let IV = Hash(file) in concatenate(IV, encrypt(IV, Key2, file)). Except that sending IV in the clear opens a dictionary attack on the contents of file. So to fix that I was going to do this: let IV = HMAC(Key1, file) in concatenate(IV, encrypt(IV, Key2, file)). Except that doesn't gain anything over the previous one if Key1 isn't kept secret. So now what I'm thinking is to do this: let IV = encrypt(one-block-mode(***), Key1, Hash(file)) in concatenate(IV, encrypt(IV, Key2, file)). Again, sorry for the length, but I hope that de-mystifies some of why I want to keep the key secret. (*) Yes, this would open up a dictionary attack if the attacker could use the backup system as an encryption oracle. Fortunately, due to external factors, in our situation the attacker can't inject arbitrary data into the backup system and thus can't use it as an oracle. (**) This is the same dictionary attack as in "(*)" except that now the attacker is attacking the IV and doesn't need to use the backup system as an oracle. He can just run the hash algorithm himself. (***) We don't need a block-cipher mode here (it's basically ECB mode) if we ensure that the hash length matches the cipher block length. Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu, Oct 1, 2009 at 5:44 PM, Michael S. Zick wrote: > Misplaced security barrier - > The user should be sufficiently security qualified to see what they type. > Everbody in the same room should be sufficiently security qualified > to see anything typed within that room. > The room should be sufficiently security qualified to exclude others. > > In some installations, the red lights on the walls and ceilings flash > and the screens are all blanked if someone with less than a certain > minimum security qualification level is allowed entry. > And if that unqualified person unblanks a screen and types ps -f : simple, > shoot them. > (I was one of the guys that carried the gun in the room for years.) > > Other than those operational procedures, you should at least write > your own application that does not disclose what you want hidden. With "ps -f" someone else in *another* room can see the command line arguments of programs that I run. You wouldn't "chmod a+r" your key files now would you? Having key contents appears as a command line argument does effectively that for the duration of the command execution. Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure Command Line MAC Computation
On Thu, Oct 1, 2009 at 4:24 PM, Ger Hobbelt wrote: > A note about your mention of 'security leak': when you are worried > about adversaries who can run 'ps -l' on your machine, then you're > essentially worried about adversaries with plenty of access to your > machine, so they'll quite probably be able to 'cat' that keyfile Any normal user on a Linux machine would be able to see 'ps -f'. But to 'cat' the keyfile or coredump the app, they would need to either (1) have root access, or (2) have cracked the machine. In my mind there is a large leap between 'normal users could get this secret info' and 'user's with root access could get this secret info'. Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Secure Command Line MAC Computation
How would I securely compute a MAC for a file? The obvious way (below) has a security leak as it puts the key on the command line which other users could easily observe with "ps -f". $ openssl dgst -sha1 -hmac I would have thought that something like "openssl enc" has with "-pass file:" would be available, but I haven't been able to find an equivalent for "openssl dgst" (even the 1.0beta's "-macopt" flag doesn't do this). Am I missing something here? What is the proper way to compute a MAC on the command line? Michael D. Adams __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
Dave, Thank you for your kind help, I really appreciate it. I forgot to mention in my last email, which showed the results of the crash,..That it was running s_client. Thanks again, -Mike --- On Wed, 9/30/09, Dave Thompson wrote: > From: Dave Thompson > Subject: RE: trying to understand ECDHE operations > To: openssl-users@openssl.org > Date: Wednesday, September 30, 2009, 5:53 PM > > From: owner-openssl-us...@openssl.org > On Behalf Of Michael D > > Sent: Wednesday, 30 September, 2009 13:12 > (superseding previous, I assume) > > > Ok, I reran my tests again...This time I added the > > -named_curve parameter...and do indeed get 50 byte key > for > > the prime192v1 curve. > > > > However, if I run the server with my certificate and > key, the > > client crashes processing the certificate. > > > s_client or something else? can you narrow it down? > > > One more question. If the public key is in the > certificate, > > why does the server send a server key exchange? > > > ECDHE = Elliptic Curve Diffie-Hellman EPHEMERAL > > Like DHE = Diffie-Hellman Ephemeral, both parties choose > per-session(handshake) DH keypairs X,Y. Server sends Ys > in ServerKeyExchange, client sends Yc in > ClientKeyExchange. > The only difference is DHE uses Z_p, ECDHE uses elliptic. > The key in the cert is used only for authentication > (signing). > > Static aka fixed ECDH (or DH) does use the certified key as > the > server part of keyagreement. Client similarly if client > auth > i.e. cert is used, which it usually isn't; but even though > that > gives a fixed (EC)DH result, SSL still makes the > sessionkeys > unique by adding per-session/handshake nonces. > > > > __ > OpenSSL Project > > http://www.openssl.org > User Support Mailing List > openssl-users@openssl.org > Automated List Manager > > majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Crash!! trying to understand ECDHE operations
I don't mind digging in and trying to figure out why the crash.. but could somebody point me in the right direction? Thanks, Mike CONNECTED(0003) depth=0 /C=US/ST=Minnesota/L=Tonka/O=IWP/OU=t1/CN=Mike/emailaddress=m...@go.metrstate.edu verify error:num=18:self signed certificate verify return:1 depth=0 /C=US/ST=Minnesota/L=Tonka/O=IWP/OU=t1/CN=Mike/emailaddress=...@go.metrstate.edu verify return:1 *** glibc detected *** /home/mike/openssl-1.0.0-stable-SNAP-20090821/apps/openssl: double free or corruption (!prev): 0x09c64410 *** === Backtrace: = /lib/i686/cmov/libc.so.6[0xb7ea1624] /lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7ea3826] /home/mike/openssl-1.0.0-stable-SNAP-20090821/apps/openssl[0x80c5365] === Memory map: 08048000-081f5000 r-xp 03:01 707408 /home/mike/openssl-1.0.0-stable-SNAP-20090821/apps/openssl 081f5000-0820 rwxp 001ad000 03:01 707408 /home/mike/openssl-1.0.0-stable-SNAP-20090821/apps/openssl 0820-08205000 rwxp 0820 00:00 0 09c34000-09c7c000 rwxp 09c34000 00:00 0 [heap] b7d0-b7d21000 rwxp b7d0 00:00 0 b7d21000-b7e0 ---p b7d21000 00:00 0 b7e19000-b7e25000 r-xp 03:01 2793475/lib/libgcc_s.so.1 b7e25000-b7e26000 rwxp b000 03:01 2793475/lib/libgcc_s.so.1 b7e32000-b7e33000 rwxp b7e32000 00:00 0 b7e33000-b7f88000 r-xp 03:01 2802825/lib/i686/cmov/libc-2.7.so b7f88000-b7f89000 r-xp 00155000 03:01 2802825/lib/i686/cmov/libc-2.7.so b7f89000-b7f8b000 rwxp 00156000 03:01 2802825/lib/i686/cmov/libc-2.7.so b7f8b000-b7f8e000 rwxp b7f8b000 00:00 0 b7f8e000-b7f9 r-xp 03:01 2802828/lib/i686/cmov/libdl-2.7.so b7f9-b7f92000 rwxp 1000 03:01 2802828/lib/i686/cmov/libdl-2.7.so b7f9d000-b7fa rwxp b7f9d000 00:00 0 b7fa-b7fa1000 r-xp b7fa 00:00 0 [vdso] b7fa1000-b7fbb000 r-xp 03:01 2793474/lib/ld-2.7.so b7fbb000-b7fbd000 rwxp 0001a000 03:01 2793474/lib/ld-2.7.so bfba8000-bfbbd000 rwxp bffeb000 00:00 0 [stack] --- On Wed, 9/30/09, Michael D wrote: > From: Michael D > Subject: RE: trying to understand ECDHE operations > To: openssl-users@openssl.org > Date: Wednesday, September 30, 2009, 12:11 PM > Ok, I reran my tests again...This > time I added the -named_curve > parameter...and do indeed get 50 byte key for the > prime192v1 curve. > > However, if I run the server with my certificate and key, > the > client crashes processing the certificate. > > One more question. If the public key is in the > certificate, why > does the server send a server key exchange? > > Thank you everybody for your help. > > -Mike > > > --- On Tue, 9/29/09, Michael D > wrote: > > > From: Michael D > > Subject: RE: trying to understand ECDHE operations > > To: openssl-users@openssl.org > > Date: Tuesday, September 29, 2009, 6:52 PM > > Dave, > > > > Thank you very much for your efforts. > > I must be doing something incorrect, as today I tried > to > > re-run > > what I had done before, and the Linux PC running the > > s_client > > crashes processing the certificate. I am running > > snapshot > > builds. > > > > If you don't mind me pestering a bit more, how did you > run > > > > the test? > > > > Thanks, I appreciate your help. > > Mike > > > > > > > > --- On Mon, 9/28/09, Dave Thompson > > wrote: > > > > > From: Dave Thompson > > > Subject: RE: trying to understand ECDHE > operations > > > To: openssl-users@openssl.org > > > Date: Monday, September 28, 2009, 7:16 PM > > > > From: owner-openssl-us...@openssl.org > > > On Behalf Of Michael D > > > > Sent: Friday, 25 September, 2009 09:32 > > > > > > > Thank you for your reply. > > > > Maybe we can drill down on the client key > > exchange > > > message first. > > > > Looking at the rfc I see it should hold: > > > > ECPoint ecdh_Yc; > > > > > > > > But for the prime192 curve, I would have > expected > > an > > > > uncompressed point to be only 48 bytes. > > > > > > > > The size of the client key exchange message > is > > 66 > > > bytes. > > > > > > > > What is in the remaining bytes? > > > > > > > First, a caveat: I set up a test to verify my > > > understanding, > > > and found (to my surprise) that s_server at > least > > doesn't > > > try > > > to use the same curve for kECDHE as for aECDSA; > it's > > a > > >
RE: trying to understand ECDHE operations
Ok, I reran my tests again...This time I added the -named_curve parameter...and do indeed get 50 byte key for the prime192v1 curve. However, if I run the server with my certificate and key, the client crashes processing the certificate. One more question. If the public key is in the certificate, why does the server send a server key exchange? Thank you everybody for your help. -Mike --- On Tue, 9/29/09, Michael D wrote: > From: Michael D > Subject: RE: trying to understand ECDHE operations > To: openssl-users@openssl.org > Date: Tuesday, September 29, 2009, 6:52 PM > Dave, > > Thank you very much for your efforts. > I must be doing something incorrect, as today I tried to > re-run > what I had done before, and the Linux PC running the > s_client > crashes processing the certificate. I am running > snapshot > builds. > > If you don't mind me pestering a bit more, how did you run > > the test? > > Thanks, I appreciate your help. > Mike > > > > --- On Mon, 9/28/09, Dave Thompson > wrote: > > > From: Dave Thompson > > Subject: RE: trying to understand ECDHE operations > > To: openssl-users@openssl.org > > Date: Monday, September 28, 2009, 7:16 PM > > > From: owner-openssl-us...@openssl.org > > On Behalf Of Michael D > > > Sent: Friday, 25 September, 2009 09:32 > > > > > Thank you for your reply. > > > Maybe we can drill down on the client key > exchange > > message first. > > > Looking at the rfc I see it should hold: > > > ECPoint ecdh_Yc; > > > > > > But for the prime192 curve, I would have expected > an > > > uncompressed point to be only 48 bytes. > > > > > > The size of the client key exchange message is > 66 > > bytes. > > > > > > What is in the remaining bytes? > > > > > First, a caveat: I set up a test to verify my > > understanding, > > and found (to my surprise) that s_server at least > doesn't > > try > > to use the same curve for kECDHE as for aECDSA; it's > a > > separate > > choice, and defaults to sectp163r2. Are you sure > either > > your > > server or your client is selecting (forcing) > prime192r1 for > > > > keyagreement AS WELL AS signing/authentication? > > > > That said, I get *49* bytes of ECDH data (Yc), plus a > > 1-byte > > length prefix totalling 50, in a ClientKeyExchange > message > > > > totalling 54, in a (clear) handshake record totalling > 59. > > Combined with other records/messages into a TCP > segment > > etc. > > > > If that's not what you got, you did something > different. > > > > > > > > > __ > > OpenSSL Project > > > > http://www.openssl.org > > User Support Mailing List > > openssl-users@openssl.org > > Automated List Manager > > > > majord...@openssl.org > > > __ > OpenSSL Project > > http://www.openssl.org > User Support Mailing List > openssl-users@openssl.org > Automated List Manager > > majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
Dave, Thank you very much for your efforts. I must be doing something incorrect, as today I tried to re-run what I had done before, and the Linux PC running the s_client crashes processing the certificate. I am running snapshot builds. If you don't mind me pestering a bit more, how did you run the test? Thanks, I appreciate your help. Mike --- On Mon, 9/28/09, Dave Thompson wrote: > From: Dave Thompson > Subject: RE: trying to understand ECDHE operations > To: openssl-users@openssl.org > Date: Monday, September 28, 2009, 7:16 PM > > From: owner-openssl-us...@openssl.org > On Behalf Of Michael D > > Sent: Friday, 25 September, 2009 09:32 > > > Thank you for your reply. > > Maybe we can drill down on the client key exchange > message first. > > Looking at the rfc I see it should hold: > > ECPoint ecdh_Yc; > > > > But for the prime192 curve, I would have expected an > > uncompressed point to be only 48 bytes. > > > > The size of the client key exchange message is 66 > bytes. > > > > What is in the remaining bytes? > > > First, a caveat: I set up a test to verify my > understanding, > and found (to my surprise) that s_server at least doesn't > try > to use the same curve for kECDHE as for aECDSA; it's a > separate > choice, and defaults to sectp163r2. Are you sure either > your > server or your client is selecting (forcing) prime192r1 for > > keyagreement AS WELL AS signing/authentication? > > That said, I get *49* bytes of ECDH data (Yc), plus a > 1-byte > length prefix totalling 50, in a ClientKeyExchange message > > totalling 54, in a (clear) handshake record totalling 59. > Combined with other records/messages into a TCP segment > etc. > > If that's not what you got, you did something different. > > > > __ > OpenSSL Project > > http://www.openssl.org > User Support Mailing List > openssl-users@openssl.org > Automated List Manager > > majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
Thank you for your reply. Maybe we can drill down on the client key exchange message first. Looking at the rfc I see it should hold: ECPoint ecdh_Yc; But for the prime192 curve, I would have expected an uncompressed point to be only 48 bytes. The size of the client key exchange message is 66 bytes. What is in the remaining bytes? Thanks, -Mike --- On Thu, 9/24/09, Dave Thompson wrote: > From: Dave Thompson > Subject: RE: trying to understand ECDHE operations > To: openssl-users@openssl.org > Date: Thursday, September 24, 2009, 6:23 PM > > From: owner-openssl-us...@openssl.org > On Behalf Of Michael D > > Sent: Thursday, 24 September, 2009 09:12 > > > I have been playing with an the command line tools of > open > > SSL and am examining traces in hopes to get an > understanding > > of how ECDHE works in real life. > > > Remember commandline s_client and s_server can do their own > > 'tracing' (-msg and -debug displays); that may be helpful. > > > My confusion focuses on the Client Key Exchange, > Change > > Cipher Spec, Encrypted Handshake message. > > > > The server has selected: > > TLS_ECDHE_ECDSA_WITH_AES256_CBC_SHA (0x00a) for the > cipher suite. > > > > My EC Public Key is: (from my certificate) > > > > 04:b9:53:3e:60:db:02:2c:6e:c4:ed:15:95:87:26: > > > > 1b:c9:96:ae:c9:a8:64:03:3a:6a:8d:14:ce:69:05: > > > > fc:4b:ea:4c:ed:a1:7f:6e:9f:37:74:20:f0:42:e2: > > > 69:a0:02:48 > > The algorithm is: > > > ASN1 OID: prime192v1 > > > > For ECDHE (E=ephmeral) the key in the cert is only for > signing. > The key-agreement key is in ServerKeyExchange for the > server, > and ClientKeyExchange for the client. I believe technically > > those don't have to be the same parameters (hence point > size) > as the signing key, but in practice they probably will be. > > > So, to make this short, what exactly is contained in > the: > > - Client Key Exchange message? > > Is this the clients 'public > key', so should be the same size > > as the server public key? > > > The same size as the server's (ephemeral) *key-agreement* > key, yes, > which as above is *probably* the same as the fixed-signing > key. > > > - Change cipher spec. > > Does this tell the server server > to switch to the AES256? > > > There is a ChangeCipherSpec message in each direction. Each > one > tells the recipient of that message to begin using the > ciphersuite > and (session) keys determined by the handshake, which in > this case > is AES256-CBC and HMAC-SHA1. > > > - Encrypted handshake message? > > Does this contain a new key > with which to use with AES256? > > > The first message you see after ChangeCipherSpec, again in > each > direction, is actually the Finished message. It contains a > (quasi) > signature of the handshake sequence, which verifies the > handshake > wasn't tampered with. It shows up in a trace only as > 'encrypted > handshake message' because it is encrypted and so the trace > tool > can't decode its contents. Unless you have an SSL-aware > trace tool > with the privatekey material(s?) available to it. > > The session keys are derived from the 'premaster secret' > agreed by > the handshake plus nonces from each party in the Hello > messages. > This derivation is the same for all ciphersuites, only the > premaster > secret agreement varies; for ECDH(E) it uses elliptic > Diffie-Hellman. > > > > > __ > OpenSSL Project > > http://www.openssl.org > User Support Mailing List > openssl-users@openssl.org > Automated List Manager > > majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
trying to understand ECDHE operations
Hello, I have been playing with an the command line tools of open SSL and am examining traces in hopes to get an understanding of how ECDHE works in real life. My confusion focuses on the Client Key Exchange, Change Cipher Spec, Encrypted Handshake message. The server has selected: TLS_ECDHE_ECDSA_WITH_AES256_CBC_SHA (0x00a) for the cipher suite. My EC Public Key is: (from my certificate) 04:b9:53:3e:60:db:02:2c:6e:c4:ed:15:95:87:26: 1b:c9:96:ae:c9:a8:64:03:3a:6a:8d:14:ce:69:05: fc:4b:ea:4c:ed:a1:7f:6e:9f:37:74:20:f0:42:e2: 69:a0:02:48 The algorithm is: ASN1 OID: prime192v1 So, to make this short, what exactly is contained in the: - Client Key Exchange message? Is this the clients 'public key', so should be the same size as the server public key? - Change cipher spec. Does this tell the server server to switch to the AES256? - Encrypted handshake message? Does this contain a new key with which to use with AES256? Thank you, I appreciate any help. Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ECDHE help needed, please
Thank you for your reply. If I understand correctly, by specifying the 'nocert' option when starting s_server, I am limiting the cipher suites to those without certificates. Otherwise I need to create a certificate and cipher suites that require certificates won't work. Does open ssl support the TLS_ECDH_anon .. cipher suites? Last question. (for now..and thank you) How can a generate an elliptic curve certificate? I tried a few things unsuccessfully to make a certificate, so some tips would really be appreciated. Thank you, Mike --- On Sat, 8/22/09, Dr. Stephen Henson wrote: > From: Dr. Stephen Henson > Subject: Re: ECDHE help needed, please > To: openssl-users@openssl.org > Date: Saturday, August 22, 2009, 1:19 PM > On Sat, Aug 22, 2009, Michael D > wrote: > > > > > I am testing a custom TLS client I am writing for a > night class. > > I would like to use openssl s_server for the testbed, > if that is possible. > > > > I am running openssl-1.0.0-stable-SNAP-20090821 > > > > * I am running the command as follows: > > openssl s_server -nocert > > > > It starts by saying: > > Using default temp DH parameters > > Using default temp ECDH parameters > > ACCEPT > > > > * My client sends a client hello. I have openssl > dump the server cipher > > list and the list I sent. > > Ming are shown as below: > > 0x81f8390:ECDHE-ECDSA-AES128-SHA > > 0x81f83c0:ECDHE-ECDSA-AES256-SHA > > 0x81f83f0:ECDH-RSA-NULL-SHA > > 0x81f8420:ECDH-RSA-RC4-SHA > > > > I end up with an error: > > 3085114028:error:1408A0C1:SSL > routines:SSL3_GET_CLIENT_HELLO:no shared > cipher:s3_srvr.c:1138: > > > > I see my cipher in the list! What am I doing > wrong please. > > > > This is getting a tiny bit frustrating. Any help > would be appreciated. > > > > Those ciphersuites all require a certificate. If the client > uses OpenSSl you > have to explicitly enable anonymous ciphersuites using an > appropriate cipher > string for example "aNULL". If the client doesn't use > OpenSSL then it may not > support anonymous ciphersuites at all. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > __ > OpenSSL Project > > http://www.openssl.org > User Support Mailing List > openssl-users@openssl.org > Automated List Manager > > majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ECDHE help needed, please
I am testing a custom TLS client I am writing for a night class. I would like to use openssl s_server for the testbed, if that is possible. I am running openssl-1.0.0-stable-SNAP-20090821 * I am running the command as follows: openssl s_server -nocert It starts by saying: Using default temp DH parameters Using default temp ECDH parameters ACCEPT * My client sends a client hello. I have openssl dump the server cipher list and the list I sent. Ming are shown as below: 0x81f8390:ECDHE-ECDSA-AES128-SHA 0x81f83c0:ECDHE-ECDSA-AES256-SHA 0x81f83f0:ECDH-RSA-NULL-SHA 0x81f8420:ECDH-RSA-RC4-SHA I end up with an error: 3085114028:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1138: I see my cipher in the list! What am I doing wrong please. This is getting a tiny bit frustrating. Any help would be appreciated. Thank you, -Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
