Re: OpenSSL error: sslv3 alert bad record mac (fwd)
Hi, this (openssl-dev) is indeed the wrong list. openssl-users might be better suited, but your problem seems to be application / configuration related. imapd-ssl: couriertls: read: error:140943FC:SSL routines: SSL3_READ_BYTES:sslv3 alert bad record mac I've had 'bad record mac' errors when I've tried to connect to an SSL v3 server; - for the long story, see among others http://www.mail-archive.com/[EMAIL PROTECTED]/msg11211.html - or search for 'bad record mac' in the archive to see all related messages http://www.mail-archive.com/[EMAIL PROTECTED]/ From the error message you've mentioned, your problem might be similar. If so, it might help to look into the config files of your imap server and pine, and make sure that you use TLS / SSL v3.1, and not limit usage to SSLv3. And make sure to forbid the usage of SSL v2.0, as its usage should be avoided (there are some attacks known against SSL v2.0). Best Regards Good luck, David Maurus Jason A. Pfeil wrote: Greetings List! My apologies for cross-posting this request, however since I have receved exactly zero replies to this or my previous message, I fear that my choice of list to send this to was wrong. To try and correct that if necessary, and to hopefully receive some information, I have posted this message to this list. Please accept my apology if this message is not germane to this list, but I have absolutely no idea what can cause this error, nor how to remedy the problem. If anyone on this list can provide some information or direction, I will be eternally grateful. I wish everyone a pleasant day! __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES counter mode
Michael Sierchio wrote: Completely. If we have confidence in the cipher and the secrecy of the key, make the nonce all zeroes. There's good reason for not doing this in the case of IPsec, but not for SSL/TLS. In theory, you may be right ;-). But: For one, I think that it can't hurt NOT to have complete confidence in the cipher. I prefer to err on the safe side. E.G. if an attack profits from having the same plaintext encrypted twice with different cipher texts, we would encounter these conditions a lot in http over SSL/TLS. This would be avoided by a nonce in the IV. And also, we should take into account that a lot of people use OpenSSL's crypto routines in another context than SSL/TLS. Best Regards, David __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES counter mode
Steven, Stephen Sprunk wrote: Thus spake David Maurus [EMAIL PROTECTED] I assume that 'number /nonce/' should mean the result of the concatenated parts of the IV. No, in the proposal to NIST (by Lipmaa, Rogaway and Wagner), 'nonce' refers to the top 64 bits and 'ctr' refers to the lower 64 bits. Where did you find that? Is it possible that you've got an older version? In Nist's sp800-38a, available at http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf the corresponding paragraph concerning counter mode with nonces reads (page 19): A second approach to satisfying the uniqueness property across messages is to assign to each message a unique string of b/2 bits (rounding up, if b is odd), in other words, a message nonce, and to incorporate the message nonce into every counter block for the message. The leading b/2 bits (rounding up, if b is odd) of each counter block would be the message nonce, and the standard incrementing function would be applied to the remaining m bits to provide an index to the counter blocks for the message. Thus, if N is the message nonce for a given message, then the jth counter block is given by Tj = N | [j]m, for j = 1n. The number of blocks, n, in any message must satisfy n 2m. A procedure should be established to ensure the uniqueness of the message nonces. In the middle of this quotation you'll find the sentence: 'The leading b/2 bits (rounding up, if b is odd) of each counter block would be the message nonce, and the standard incrementing function would be applied to the remaining m bits to provide an index to the counter blocks for the message. I think this is clear on the fact that e.g. with a 128 bit 'counter block' / IV, you'd use the leading 64 bits for the nonce (I'd interpret 'leading' as the Most Significant Bits, if the bits would represent a number), while the remaining 64 bits of the 'counter block' / IV are the bits that are actually counting up, i.e. get incremented. Unfortunately, the current API has no way to report no more encryption possible, you must rekey. Given this limitation, two silent failure modes are possible: either wrap and reuse ctr values, or don't wrap and use nonce values the user didn't specify. As I pointed out (I think), if you let the user provide an IV, let's say a 128 bit IV, and make clear in the documentation that the best way to use it would be to fill the highest 64 bit with a unique nonce, and clear the lowest 64 bits, as they will be used as a counter, there will be no problem. We could word the usage instructions even more general, saying that the lowest bits get used as counter, and that no more blocks should be encrypted with the same key and that counter, as the bits used as counter allow. 32bit counters can wrap in under a minute; IPsec clearly has a pressing problem, but I'm not sure how to code to support both without giving up and making the ctr-increment function a user parameter. You're right. While as Lee Dilkie pointed out, the IPSec message format will not allow that this 32 bit counter will overflow, I'd like to refrain from my previous recommendation to 'follow the IPSec draft as close as possible' in this issue, since 32 bit are obiously not enough for SSL. Per the NIST spec, the next nonce chosen will be the old nonce plus one, so the user's choice will always be unlucky. Again, in the version of the NIST document I've linked to above, I can't find a statment that the nonce is to be incremented. I can only find the requirement that the nonce must be unique for the encryption key. The easiest way to go about it would be to increment the user supplied IV by 1 for each encrypted block, and leave it to the user of this function to make sure that no overflow in the counter can occur. This obligation to the programmer should be written somewhere in big letters ;-) (i.e. DON'T USE COUNTER MODE TO ENCRYPT MORE THAN 2**32 [or 2**64, depending on the counter size] BLOCKS WITH THE SAME KEY!). Higher level routines, i.e. the SSL BIO, should avoid counter overflows automatically for the user by initiating a rehandshake. While this option is tempting, and the user does have access to the counter at all times to check for impending overflow, experience shows that programmers ignore such warnings more often than not. Of course I'd be glad if we could check the counter and throw an exception when it overflows, but the interface for the low level crypto routines doesn't seem to accommodate that. All functions return a 'void', e.g. nothing. I assume we cannot change that. (without breaking other parts). Best Regards, - David __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES counter mode
Gtz Babin-Ebell wrote: The application specifies 4 datas: 1. a step size 2. a bit mask. 3. a (optional) pointer to a function that is called if the step bits that are not in the bit mask: 4. a (optional) pointer to a function doing the counting; if (pCounter-Range) return pCounter-Range(pCounter); else return Range_restart(pCounter); The quoted code would restart counting when the counter overflows. That would open up a predictable opportunity for attack. I am still convinced that the default behaviour should be to report an error, and if this is not possible, increment over the bit-bound of the counter (increment the nonce), as this would cause the least damage. The idea to have a function pointer for the increment function has the advantage that one could implement a counter function that would actually not count incrementally, but otherwise unique, as alluded to in the NIST recommendation (also page 19): This recommendation permits the use of any other incrementing function that generates n unique strings of m bits in succession from the allowable initial strings. For example, if the initial string of m bits is not the zero string, i.e., if it contains at least one 1 bit, then an incrementing function can be constructed from a linear feedback shift register that is specialized to ensure a sufficiently large period; see Ref. [5] for information about linear feedback shift registers. But then, a mask based range check would not be sufficient, since you can't rely on any overflows. In general, I'd prefer a more simple approach, like taking the counter bits as a parameter, and returning an int code ERR_LIB_NONE (?) if everything's OK, and an something like ERR_AES_CTR_OVERFLOW when the counter overflows... - David __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES counter mode
Stephen Sprunk wrote: In the specification of CTR mode, as proposed for AES, you will find the statement The number /nonce/ is incremented following each encryption. I interpreted this to mean that the top 2^64 bits are to be incremented for each successive block, and this is how I implemented the code. I assume that 'number /nonce/' should mean the result of the concatenated parts of the IV. In case of the AES-CTR IPSec draft, you get the IV by concatenating a msg number, a nonce, and the counter (at start initialized to 0). You can then safely incerement the 128 bit IV, *unless* you overflow the counter part (the lower 32 bits of the IV, according to the AES-CTR IPSec draft). Further review has indicated everyone else seems to think this means the nonce is incremented only between streams and it's the counter that is incremented between blocks; If you have a message number in the IV, you'd naturally incement the message number for each message (each message consisting of an arbitrary number of blocks), but then you'd also clear the counter to 0 and maybe even choose a new random nonce part. In the Schneier / Fergusson example, a 48 bit message number, a 16 bit random part and a 64 bit counter are used. When you start a new message, from my understanding you'd clear bits 0-63, and increment the msg number spanning bits 80-127. Probably, if your protocol or format allows for it, you'd also choose a new nonce (i.e. fill bits 64-79 with new random data). Since the recepient of the encryptded data can't guess the 16 bit random part if it changes, it is necessary to prepend the new IV, and accomodate for that in the message format or communication protocol. For online transmissions, it would be reasonable to start a re-keying handshake for this. On the matter of overflowing the lower 64 bits, this is not specifically addressed in the submission (I think they assumed nobody would exceed 2^64 blocks per stream, which is reasonable) and thus I think wrapping is the correct failure. I'm not sure what you mean with 'the correct failure', but the clean way to handle a counter overflow would be to fail / report an error, instead of continuing to encrypt. But this is also a matter of interoperability. Since you should not wrap the counter around (as it would offer a weakness for attackers), nobody who is trying to decrypt the data would expect to allow for wrapping. On the other hand, the same function is used for decrypting and encrypting, and when decrypting, failing might be worse than continuing. This discussion is academic for 64 bit counters, of course, as you probably won't see a 64 bit counter wrap very often. With a 32 bit counter however, the risk is a lot higher. Unfortunately, the current basic crypto functions offered by OpenSSL don't support returning an error condition, so 'failing' is not an option anyway. To increment the nonce introduces a more insidious failure mode where the user unintentionally reuses nonces. It is debatable whether wrapping the counter would be less bad than incrementing the nonce part. A wrapping counter is more predictable for an attacker (as it would occur *always* when the communication exceeds 2**32 or 2 **64 blocks) than an unlucky nonce choice. In other words: If we let the counter wrap, the user is always affected when the counter overflows, and the weak spot is predictable. If we allow to increment the nonce instead of wrapping the counter, the user is only affected when the counter overflows, *and* he continues to reuse the same key but chooses a new nonce, *and* the choosen nonce value collides with the incremented nonce. Other specifications have suggested that nonce be of unspecified length, not exactly 64 bits; this implies that the lower bits wrap in an overflow condition, otherwise there would be no need to specify a boundary between the different parts of counter at all. I think the intention of the boundary for the counter part is NOT to allow for wrapping, but to have a mechanism in place to ensure that a single IV (nonce + counter) is not used twice. If you just seeded the whole 128 bits with random data, and incremented them as if the counter was 128 bit, *and* you were using the same symmetric key for more than one message / transmission, you could be unlucky (most likely if your PRNG is suboptimal) and generate an IV that you've used already because of the counting. Separating the counter and the nonce leads to having a minimum distance of 32 or 64 bits between IVs, when you are careful to always use a fresh random nonce part. Implementing a mechanism to avoid collisions of IVs would be cumbersome otherwise. Unfortunately, implementing this (as has been requested) would require more significant changes to the API than I know how to make,as passing parameters to a mode doesn't appear to be supported today. The easiest way to go about it would be to increment the user supplied IV by 1 for each
Re: AES counter mode
Thierry Boivin [EMAIL PROTECTED] said:
Thierry.Boivin My understanding of this one is (in a practical perspective) is :
Thierry.Boivin calling programs maintain a 64 bit long nonce counter.
This is not correct - to quote from the (btw excellent) new book from Bruce
Schneier and Neils Fergusson ('Practical Cryptography'), Page 75:
'CTR [Counter Mode] uses a remarkably simple method to generate the key stream. It
concatenates the nonce with the counter value, and encrypts it to form a single block
of the key stream. This requires that the counter and the nonce fit in a single block,
but with the modern 128-bit block sizes, this is rarely a problem. Oviously, the nonce
must be smaller than a single block, as there needs to be room for the counter value
i. A typical setup might use a 48-bit message number, 16 bits of additional nonce
data, and 64 bits for the counter i. This limits the system to encrypting 2**48
different messages using a single key, and limits eacht message to 2**68 bytes'
So apparently, the trick would be to leave the nonce untouched in the higher 64 bits, and increment the 64 lower bits. Instead of overflowing to bit 65 after 2**64 message blocks, the sensible option would be to stop the encryption with this key, and choose a new one. If we would continue counting despite the overflow into the nonce, we would risk to use (or better: have no mechanism in place to avoid using) the same key with the same 128 bit nonce/counter value twice, which would generate the same cipher output block again, which would mean that we would XOR different parts of the plain text with the same cipher bits, opening an opportunity for attack (albeit a very small one).
Richard Levitte - VMS Whacker wrote:
And when should the increment by 2^64 occur? Is that something that
the application should make sure happens with some kind of call to the
currently non-existing functino AES_incr_ctr() (perhaps done in
EVP_EncryptFinal())?
If everyone can agree on such an interpretation, I have no problems
changing it, as long as it also makes the implement crunch the
available test vectors properly.
Well, incrementing by 2**64 would only be reasonable if the nonce would
be in the lower 64 bits of the 128 bit nonce/counter value.
Best Regards,
David
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: AES counter mode
Michael Sierchio wrote: Using AES Counter Mode With IPsec ESP - This mandates a 32-bit counter, requiring rekeying after 2^48 octets of stream material. Ah, this is interesting. Considering that OpenSSL is not only used for SSL / TLS encryption, and the mentioned RFC proposes to use a 32 bit counter and a 96 bit nonce, whereas other specs (NIST SP 800-38A) as you mention propose a 64 bit counter and a 64 bit nonce, it might be good to expose these differences in the interface of the crypto function and leave this choice to the caller. There also should be an error condition indicating that no further plaintext can be encoded unless a new key and nonce were generated (i.e. in an SSL/TLS context, a new handshake is required). Using AES Counter Mode With IPsec ESP - This mandates a 32-bit counter, requiring rekeying after 248 octets of stream material. The counter would overflow after the transmission of 2**32 blocks, a block being 2**4 octets (128 bits, 16 octets), so rekeying should be necessary after 2**36 octets (= 64 GB). http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-04.txt Argument: let's write an Internet draft that describes the use of AES CTR mode in SSLv3/TLSv1. We can do it however we like, modulo the usual criticism and review in the IETF working group(s). I'd support that, too. If this is done, I would propose to follow the ipsec draft as much as possible (and RFC 3268 of course, which extended TLS/SSL for AES originally - http://www.ietf.org/rfc/rfc3268.txt). There is no need to reinvent the wheel, and the 96 bit nonce / 32 bit counter is indeed appropriate for the bulk of actual communication - it would be a very rare exception that even a 32 bit counter would overflow. - David __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Stratus OpenSSL diffs and test results.
Disclaiemr: I can't by any means give an authorative answer, since I am not part of the development team But I think you should consider the following: - if you are in the US, you should send every source code contribution in CC to [EMAIL PROTECTED] - I think that it's not so nice to include your own copyright notice in the diffs where you essentially changed openssl example source code (if that is the case - it seems to be so from what I gather by looking at the diff briefly). If you want to officially contribute this port, you should be aware that OpenSSL is licensed with an Apache Style license. - In case this port is appreciated by the developers (can't speak for them), a patch against 0.9.7 might be useful, since 0.9.6d won't be change much as it is now in beta Best Regards, David __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Stratus OpenSSL diffs and test results.
Disclaiemr: I can't by any means give an authorative answer, since I am not part of the development team But I think you should consider the following: - if you are in the US, you should send every source code contribution in CC to [EMAIL PROTECTED] - I think that it's not so nice to include your own copyright notice in the diffs where you essentially changed openssl example source code (if that is the case - it seems to be so from what I gather by looking at the diff briefly). If you want to officially contribute this port, you should be aware that OpenSSL is licensed with an Apache Style license. - In case this port is appreciated by the developers (can't speak for them), a patch against 0.9.7 might be useful, since 0.9.6d won't be change much as it is now in beta Best Regards, David Sundaram, Mani wrote: Hi, We ported OpenSSL to our operating system VOS that has a POSIX API. In addition to OpenSSL, we have successfully ported other open source software such as Gnu gcc, gdb, Gnu tools(bash, gmake, ...), Apache, Samba, Perl, Python. OpenSSL was relatively easy port. Ben Laurie suggested that we send our OpenSSL diffs to the developers for review. We would like to call our port as VOS OpenSSL; we request your permission to use the OpenSSL name. Our changes include adding header files to compile on VOS - mostly sys/types.h and sys/select.h. This is because on the Linux OpenSSL code base, time.h includes types.h and select.h whereas in VOS it does not. There are two other changes that we did to the code: 1. VOS doesn't support getrusage( ) or ftime( ). However, we do support gettimeofday( ) and times( ). We had to write a new else condition in speed.c to handle this case. We haven't modified the functionality of the code. 2. gcc -Wall warns when sprintf (foo, %d, foobar) is called (foobar is a long datatype). We fixed this. We believe that these changes are platform specific only and no functionality of the product has been compromised. We didn't delete any source code. We are enclosing the diff and the self-test results. We would appreciate your prompt reply with the approval of our changes and the use of the OpenSSL name. Please do not hesitate to contact us if you need further information. We thank you once again in developing OpenSSL. Sincerely, Bose (Engineering Manager) Mani (Software Engineer) --- Here is the diff and the OpenSSL self-test results. The porting base was revision 0.9.6; please note that we have patched md_rand.c with the security fix posted on your website. diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/app_rand.c /p/openssl/porting_base/apps/app_rand.c 145,147d144 #ifdef VOS_DEBUG printf(\n file = %s, file); #endif /* VOS */ diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/dh.c /p/openssl/porting_base/apps/dh.c 63,65d62 #ifdef __VOS__ #include sys/types.h #endif diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/dhparam.c /p/openssl/porting_base/apps/dhparam.c 115,117d114 #ifdef __VOS__ #include sys/types.h #endif diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/dsa.c /p/openssl/porting_base/apps/dsa.c 63,65d62 #ifdef __VOS__ #include sys/types.h #endif diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/dsaparam.c /p/openssl/porting_base/apps/dsaparam.c 62,64d61 #ifdef __VOS__ #include sys/types.h #endif diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/openssl.cnf /p/openssl/porting_base/apps/openssl.cnf 8a9 RANDFILE = $ENV::HOME/.rnd 36c37 dir= ./demoCA# Where everything is kept --- dir = ./demoCA # Where everything is kept 39,40c40,41 database = $dir/index.txt # database index file. new_certs_dir = $dir/newcerts # default place for new certs. --- database = $dir/index.txt# database index file. new_certs_dir = $dir/newcerts # default place for new certs. diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/pkcs7.c /p/openssl/porting_base/apps/pkcs7.c 62,64d61 #ifdef __VOS__ #include sys/types.h #endif diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/req.c /p/openssl/porting_base/apps/req.c 61,63d60 #ifdef __VOS__ #include sys/types.h #endif diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/rsa.c /p/openssl/porting_base/apps/rsa.c 63,65d62 #ifdef __VOS__ #include sys/types.h #endif diff -r -x Makefile* /p/openssl/dev.0.9/src/openssl-0.9.6/apps/s_client.c /p/openssl/porting_base/apps/s_client.c 63,68d62 #ifdef __VOS__ #include sys/types.h #include sys/select.h #endif 444,447d437 #ifdef VOS_DEBUG printf(\n WIDTH = %d\n, width); #endif 495,497d484 #ifdef VOS_DEBUG printf(\n
Re: OpenSSL/Java JSSE Handshake problem...
Andreas Sterbenz wrote: For the Sun JSSE provider, the default enabled protocols are SSLv3, TLSv1, and the pseudo protocol SSLv2Hello. The latter means that client hello messages are sent/ accepted in SSLv2 format. This is for better error diagnostic when talking to SSLv2 only implementations. After revisiting Eric Rescorla's SSL and TLS, I come to the conclusion that for the client, starting with a SSLv2 ClientHello msg would also be useful to talk to a server that might be a version 2 server. At least in SSLv3 it was specified for the server to continue with a v3 handshake, if it was able to support the version number sent be the client (see page 135 of SSL and TLS). The result is that with the default settings a V2 client hello message requesting TLS 1.0 is sent. ...which is the most compatible way to speak to any unknown SSL/TLS server. Shouldn't OpenSSL answer this v2 ClientHello with SSL-version no. 3.1 by continuing with a TLS handshake? Or was this compatibility option left out in OpenSSL by purpose? RFC2246 ( http://www.ietf.org/rfc/rfc2246 ) states (Page 65): TLS 1.0 clients that support SSL Version 2.0 servers must send SSL Version 2.0 client hello messages [SSL2]. TLS servers should accept either client hello format if they wish to support SSL 2.0 clients on the same connection port. The only deviations from the Version 2.0 specification are the ability to specify a version with a value of three and the support for more ciphering types in the CipherSpec. Warning: The ability to send Version 2.0 client hello messages will be phased out with all due haste. Implementors should make every effort to move forward as quickly as possible. Version 3.0 provides better mechanisms for moving to newer versions. Best Regards, David Maurus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PKI and sockets
Mark W. Webb wrote: I am working on an application that will implement PKI between a server and a client. That sentence is somewhat wrong: between clients and servers (i.e. 2 computers) you will need to use a protocol they adhere to when speaking to each other. PKI (Public Key Infrastructure) is not a protocol. I assume you want to secure the communication between the server and the client. SSL is a protocol that can achieve that, and incidentely OpenSSL provides the necessary functionality. Can someone tell me where I might get some sample code (C) or a tutorial on how to do it. If you download and unpack the source code of OpenSSL, there is plenty of sample source. You can find the latest version of the OpenSSL source code at http://www.openssl.org/ . There is however not much documentation for programmers besides the source code itself. I have looked at Eric Rescorla's but I am not sure how to create my own certificates to get that tutorial work, Rescorla's book is excellent, you should read it some more. You can get free trial certificates from verisign, however they are only valid for some days. http://www.verisign.com/freeGuides.html Alternatively, you can generate your own certificates with openssl, if you download the source code and compile it. You can use the openssl program via the commandline to do so, documentation can be found at http://www.openssl.org/docs/apps/openssl.html Look for the subcommands genrsa (to generate a RSA public/private keypair) req (to generate a certificate requet) x509 (to create a certificate) I can use the sample certificates he provides, but that would not be good for production. This is correct - using sample certificates in a production environment would be dangerous if they come with a know private key, and useless if they don't. Plus I would rather use PKI than certificates. As mentioned above, this is nor either/or choice. PKI relies on certificates. Sorry ;-). - David __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL/Java JSSE Handshake problem...
8E DF DD 5B 9B 22 4C 51 8E E8 DA r.6.[.LQ... 0010: ED BE A5 0F 53 S main, READ: SSL v3.1 Application Data, length = 21 Plaintext after DECRYPTION: len = 21 : 6C FF C7 5B 71 3F 71 BF 02 1A 64 DF F4 6D AC A3 l..[q?q...d..m.. 0010: 93 43 00 73 1C .C.s. main, READ: SSL v3.1 Application Data, length = 21 Plaintext after DECRYPTION: len = 21 : 64 AE 26 F2 DF A7 9F D6 E4 79 59 7B D2 77 FC 24 d...yY..w.$ 0010: 08 2F A2 3C EB ./.. etc... Kevin Regan wrote: I've run into the handshake problem with OpenSSL and Java JSSE. If I change the method used to create the SSL context from TLSv1_server_method to SSLv23_server_method, the problem is fixed. Which version of JSSE are you using, and can you provide debug output? You can get excellent verbose debug output in JSSE if you use this command line switch: -Djavax.net.debug=ssl,handshake,data,trustmanager when calling your java application, i.e. in windows java.exe -Djavax.net.debug=ssl,handshake,data,trustmanager MyClass Recently - in a rather painful process - I found the cause for a BAD RECORD MAC SSL error sent in the server hello msg, after my JSSE SSL client sent an incorrect finish msg... Best Regards, David Maurus Kevin Regan Technical Lead Houston UNIX Team Office: 2200 Phone: 713-548-1767 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL/Java JSSE Handshake problem...
Kevin Regan wrote: I've run into the handshake problem with OpenSSL and Java JSSE. If I change the method used to create the SSL context from TLSv1_server_method to SSLv23_server_method, the problem is fixed. Which version of JSSE are you using, and can you provide debug output? You can get excellent verbose debug output in JSSE if you use this command line switch: -Djavax.net.debug=ssl,handshake,data,trustmanager when calling your java application, i.e. in windows java.exe -Djavax.net.debug=ssl,handshake,data,trustmanager MyClass Recently - in a rather painful process - I found the cause for a BAD RECORD MAC SSL error sent in the server hello msg, after my JSSE SSL client sent an incorrect finish msg... Best Regards, David Maurus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Where can I get SSL library file (ssl.lib or libssl.so)
Connie Wu wrote: I have download the openssl. I can not compile any file that in the demos directory since can not find libssl.a and libcrypto.a. Do you know where or how to get those library files? After unpacking, you'll first have to ./configure openssl, then make and make install it. Then you'll find these libraries in the lib subdirectory of your ssl install directory (you can set this directory with the --prefix option of ./configure) Best Regards, David Maurus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: *.pem files
Leonid Frog wrote: I am trying to run test.bat file and I am getting error messages which refer to *.pem files in CERT folder. Do you have any idea where I can find names of PEM files which has to be in CERT folder so I can compare it to what I have? Thanks a lot for your help. The CERTS folder (note the s) in openssl.0.9.6.tar.gz contains the following files: 03.12.99 01:53 1.986 ca-cert.pem 21.12.98 11:52 2.307 dsa-ca.pem 21.12.98 11:52 2.723 dsa-pca.pem 21.12.98 11:52874 factory.pem 21.12.98 11:56 3.004 ICE-CA.pem 21.12.98 11:56 2.362 ICE-root.pem 21.12.98 11:56 3.303 ICE-user.pem 21.12.98 11:56480 ICE.crl 21.12.98 11:52916 nortelCA.pem 03.12.99 01:53 1.986 pca-cert.pem 21.12.98 11:52 1.036 rsa-cca.pem 21.12.98 11:52 1.050 rsa-ssca.pem 21.12.98 11:52 1.146 thawteCb.pem 21.12.98 11:52 1.174 thawteCp.pem 21.12.98 11:52769 timCA.pem 21.12.98 11:52886 tjhCA.pem 21.12.98 12:00 1.001 vsign1.pem 21.12.98 12:00 1.007 vsign2.pem 21.12.98 12:00 1.007 vsign3.pem 21.12.98 12:00993 vsignss.pem 21.12.98 12:00 1.102 vsigntca.pem also, there's a subfolder EXPIRED which contains the following files: 21.12.98 12:00 3.004 ICE-CA.pem 21.12.98 12:00 2.362 ICE-root.pem 21.12.98 12:00 3.303 ICE-user.pem 21.12.98 12:00480 ICE.crl Regards, David __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: WIN32 Source Compile with Microsoft VC 6.0
Jeff Roberts wrote: Can anybody direct me to the steps required to ftp, install, compile and use OpenSSL in the Microsoft Windows 32 bit environment ? Go to http://www.openssl.org/source/ and search a mirror near you, save the archive to your harddisk and then use winzip to extract it. If you don't have perl, you can use Active State Perl: http://www.activestate.com/Products/ActivePerl/Download.html You can get the Microsoft Macro Assembler for free at Microsoft http://msdn.microsoft.com/vstudio/downloads/ppack/default.asp You don't need it to compile openssl, but it runs faster when you use masm. However you have to have the Visual Studio Service Pack 4 installed, which you can find here: http://msdn.microsoft.com/vstudio/sp/vs6sp4/full.asp?id=01 Since Vs-Sp4 is a 129MB download, you can find an older version of masm in the win98 DDK: http://www.microsoft.com/hwdev/ddk/ddk98.htm (I haven't tried this myself) If you have Visual C installed, you can continue by opening a command prompt and starting \Visual Studio\vc98\bin\vcvars32.exe to set the compiler environment. This done, follow the steps in the file install.w32 that you find in the OpenSSL-Directory (type "perl Configure VC-WIN32" at the command prompt, etc.). You can find some documentation on how to use OpenSSL here: http://www.openssl.org/docs/ There's a lot you can do with the commandline utility openssl, and even more when you link to the libraries. - David Maurus PS: I`ve got the binaries up at http://www.mailbag.de/Out32dll.zip __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
