Cipher algorithm
Hi, I want to write a Client-Server-application, which connection is SSL encryted. Can I define the crypt algorithm which is negotiate while handshake? Is there a crypt algorithm which does not change the size of the data? thanks in advance Markus Wenke __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Strange problem with SSL_write
On 27 Sep 2006, at 22:28, David Schwartz wrote: Other side would return an error message: ORA-31154: invalid XML document ORA-19202: Error occurred in XML processing LSX-00213: only 0 occurrences of particle quot;greetingquot;, minimum is 1 It is totally confused, that is: i, as a client would never send greeting. One thing possible is that it got only part of the document. Second thing is two login attempts, which is an error. How is the client supposed to know where the document ends? EPP PDU starts with four bytes telling the length of the document this after one call of SSL_write. As you see, SSL is transmitting two separate application data packets. Who cares whether it sends one or a thousand? It's none of the application's business how SSL sends the data so long as it all gets to the other end in the right order. If EPP server get two login attempts during very short period, it can reject the request. Thousand login attempts would definitely be a denial of service attack, by everybody's count. The problem is having two application data packets, when i call SSL_write only once. Why do you care how many application data packets SSL uses to send the data from one end to the other? That's a protocol detail the application should not care about. Most of protocols do care about DoS. And, say, doing a database update unknown number of times is not good idea either. And yes, i want to decrypt these two packets, to see what they contain. Even if they both are valid packets, this would be an error, as i said. How would that be an error? As I said before, the relevant rfc has quite strong wording about DoS attacks. EPP would be used, for instance, provisioning ENUM DNS records, which explains the sensitivity. As for 0x00, this one is the cwise end-of-the- string. Some application have separate function call for handling date containing it.. Why do you care what bytes are in the encrypted data? You're not handling that data, OpenSSL is. You see to be very confused about how layering works in an SSL application and what interface SSL provides to the application. SSL, like TCP, is a byte-stream protocol that does not preserve message boundaries. This was just because some applications have different ways to handle octet sequence containing 0x00, which is c's end-of-the-string. I use SSL_write to send exactly one packet to the SSL socket, so expectation of of one ssl application layer packet is reasonable. Aarno __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cipher algorithm
Markus Wenke wrote: Hi, I want to write a Client-Server-application, which connection is SSL encryted. Can I define the crypt algorithm which is negotiate while handshake? Is there a crypt algorithm which does not change the size of the data? [...] Did you miss my reply? I'll cite it once more (see also the archive at http://marc.theaimsgroup.com/?l=openssl-usersm=115882610217857w=2): Hi, I want to write a Client-Server-application, which connection is SSL encryted. Can I define the crypt algorithm which is negotiate while handshake? See http://www.openssl.org/docs/ssl/SSL_CTX_set_cipher_list.html Is there a crypt algorithm which does not change the size of the data? Hmm, what is the background of this question? In principle encryption does not necessarily change the size of the data, but there is protocol overhead and padding, so in reality you will have to pay for encryption with bigger data, independent of the used algorithm. This is especially relevant when transmitting small chunks of data at a time, if you are sending Megabytes of data in quick succession I'd guess that the overhead is negligible. Hope it helps. Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Re: Strange problem with SSL_write
On 27 Sep 2006, at 22:54, Kyle Hamilton wrote: If your server (that is, the one which accepts the connection) is sensitive to the number and content of the actual packets, the server is in violation of the 'layer' boundary. SSL and TLS can be thought of as another protocol in the AF_INET family, even though it's implemented in user-level code and operates on top of TCP. Receiving SSL socket is not sensitive to number and content of application layer packets, of course. Application sitting on the top of SSL is. Too many login packets would be denial of service attack, or something worse. The SSL/TLS 'kernel' (even though it's implemented as user-level code) should be invisible to the upper layers (this is why OpenSSL implemented BIO calls, so that the same interface can be used for files, UNIX sockets, TCP sockets, and SSL/TLS-session associated sockets). If it's not, then the implementation that's complaining is in violation of the protocol. It is never an error to send an empty application data packet (unless there's a renegotiation going on). Actually EPP server is sitting on the top OpenSSL. I did not know that OpenSSL is sending (and removing) an empty packet. So I have disabled it, and will restore it, when EPP accepts the login Try disabling the Nagle algorithm on a TCP socket, and then write a bunch of stuff out and watch it in ethereal. Watch an SMTP session. Then try disabling Nagle and sending each character of an SMTP exchange out in its own write() or send() call. Watch how the behavior of the server you're communicating doesn't change regardless of how the packets are sent. I disabled the empty packets, and now i see only one application layer packet As everyone else has stated, SSL/TLS are layered on top of TCP, and present the same guaranteed-byte-order interface to its users. The application protocol gets layered on top of that, with an abstracted byte-ordered connection semantic. Thus, I don't understand why you say that having two packets going out is an error. Nor does anyone else. It's not an error, and is in fact implemented to increase the security of the connection (CBC timing attacks are possible without it). Yes, having two packets is not an error, if receiving socket removes the empty one. I was afraid (i did not decrypt) that there was two actual application layer packets. I did know about CBC timing attack, thanks to you guys explaining it to me. What I want to know is why you're getting so many TCP retransmissions -- that suggests that there's a problem at the network layer and not the SSL or TLS layer. I disabled tcp checksum checking for tshark. Otherwise, there would be endless complains about checksum errors. (Note: if you send a single 2600 byte buffer to a standard TCP socket with write() or send(), it will get broken up into multiple packets by the kernel -- yet this is not an error. Why are you stating that it is categorically an error to get two packets out of a single SSL_write(), when it provides the same semantics as the kernel write()?) As I said, I was afraid that there were two actual application layer packets (two logins), which would be regarded, at best, as a DoS attack by the application layer server. Aarno On 9/27/06, Aarno Syvänen [EMAIL PROTECTED] wrote: Hi, On 27 Sep 2006, at 10:20, David Schwartz wrote: Then the problem: when i am doing SSL_write, it does return full length of the packet i send, You don't send packets to SSL_write, you send bytes. It returns the number of bytes sent, and if the other end doesn't receive that number of bytes (possibly in multiple call to SSL_read), you have found a problem. Other side would return an error message: ORA-31154: invalid XML document ORA-19202: Error occurred in XML processing LSX-00213: only 0 occurrences of particle quot;greetingquot;, minimum is 1 It is totally confused, that is: i, as a client would never send greeting. One thing possible is that it got only part of the document. Second thing is two login attempts, which is an error. but ethereal shows *two* application level packets. It's not completely clear what you mean by application level packets. SSL is a byte-stream protocol. It guarantees only that the other end will receive the same bytes in the same order. It does not glue bytes together in a way the application can use. There is no special reason you should care (except perhaps for performance/efficiency reasons) if you send 100 bytes and SSL sends them as a single 100-byte chunk or 100 1-byte chunks tshark dump is following: 72664.019667 130.59.10.95 - 193.53.0.56 TLSv1 [TCP Retransmission] Server Hello, Certificate, Server Key Exchange, Server Hello Done 72664.035083 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=2996013302 Ack=106323215 Win=65535 Len=0 TSV=1368546303 TSER=2583245094 72664.634056 193.53.0.56 - 130.59.10.95 TLSv1 [TCP Retransmission] Client Key Exchange, Change Cipher Spec,
SSL objects in fork() - exec scenario
Hi, Mentioned below is a normal tcp scenario. Could someone tell me how the following scenario be handled in SSL secured environment A. Client establishes a tcp connection with the Server B. Server Forks. C. Server exec's to start a new process. It passes its socket descriptor to the new process as command line argument. D. The new process uses the socket descriptor to communicate with the client. The idea here is to use the existing tcp connection for communication. Now, if we have this channel secured with SSL, the Client and Server both would have their SSL objects. They will communicate securely through these SSL object. The question here is,how can we provide the required SSL object to the new process, so that it would start using the pre established secured session / channel? One possible solution I could think of is to use shared memory between the Server and new process. The server, before it exec the new process would create a copy of its SSL object in the shared memory and the new process then will use it. But I am not sure if such copying of SSL object is safe. Is there any other solution possible? Could someone guide me through this? Thank you, ~ UrjitDISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.
How to get CVE-2006-4339 patch for 0.9.5a
Hi, I use OpenSSL0.9.5a, but the patch doesn't exist about CVE-2006-4339. So I have some questions for the following reports. OpenSSL Security Advisory [5th September 2006] http://www.openssl.org/news/secadv_20060905.txt 1. Is there CVE-2006-4339 vulnerability in a version that is older than 0.9.5series? 2. How can I get this patch for 0.9.5a? Best regards Kazuaki Utsunomiya __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: SSL objects in fork() - exec scenario
In our server application we removed all fork()/exec() from our server once we started using openSSL.At that time, we were using fork/exec on some platforms, pthreads on others. We swapped the forking platforms over to use pthreads were very reliable results. I believe we saw this symptom: following SSL connect/accept, the client sends its first message, which is recv'd by the parent before it actually closes its copy of the socket. The child, the process which should be send/recv'ing with the client never sees what it expects. There's more to it than that, but I can't remember more details. If you have the freedom to use pthreads instead of fork/exec, I'd recommend it. Dave McLellan -- Common Management Platform Engineering EMC Corporation 228 South St. Mail Stop: 228 2/C-19 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Urjit GokhaleSent: Thursday, September 28, 2006 5:11 AMTo: openssl-users@openssl.orgSubject: SSL objects in fork() - exec scenario Hi, Mentioned below is a normal tcp scenario. Could someone tell me how the following scenario be handled in SSL secured environment A. Client establishes a tcp connection with the Server B. Server Forks. C. Server exec's to start a new process. It passes its socket descriptor to the new process as command line argument. D. The new process uses the socket descriptor to communicate with the client. The idea here is to use the existing tcp connection for communication. Now, if we have this channel secured with SSL, the Client and Server both would have their SSL objects. They will communicate securely through these SSL object. The question here is,how can we provide the required SSL object to the new process, so that it would start using the pre established secured session / channel? One possible solution I could think of is to use shared memory between the Server and new process. The server, before it exec the new process would create a copy of its SSL object in the shared memory and the new process then will use it. But I am not sure if such copying of SSL object is safe. Is there any other solution possible? Could someone guide me through this? Thank you, ~ UrjitDISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.
Re: linux-elf-arm configuration option missing
On Thu, Sep 28, 2006, Yugandhar wrote: Hi, I am currently using OpenSSL 0.9.7e which has the option linux-elf-arm for ARM processors.Recently i downloaded OpenSSL 0.9.8c.It seems that the linux-elf-arm option has been removed from the Configure file. Can anyone throw some light on why this option has been removed.I want to use the OpenSSL library as a shared one on IXP425 based platform? Is there an equivalent option for linux-elf-arm? Any help is greatly appreciated. That and several others have been replaced by a linux-generic32 target. Depending on the byte sex of the OS you can also use -DB_ENDIAN of -DL_ENDIAN for example: perl Configure linux-generic32 -DB_ENDIAN Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL objects in fork() - exec scenario
The possible solution is to create own SSL instance in the child process and to assign the socket returned by accept system call, i.e., before SSL handshake. The parent server process should not handle SSL for the current connection at all. E.g.: /* sock is the socket descriptor, ctx is a pointer to SSL_CTX */ ... SSL *ssl = SSL_new(ctx); SSL_set_fd(sock); ... /* continue with SSL handshake */ Thanks, Vlad On 9/28/06, Urjit Gokhale [EMAIL PROTECTED] wrote: Hi, Mentioned below is a normal tcp scenario. Could someone tell me how the following scenario be handled in SSL secured environment A. Client establishes a tcp connection with the Server B. Server Forks. C. Server exec's to start a new process. It passes its socket descriptor to the new process as command line argument. D. The new process uses the socket descriptor to communicate with the client. The idea here is to use the existing tcp connection for communication. Now, if we have this channel secured with SSL, the Client and Server both would have their SSL objects. They will communicate securely through these SSL object. The question here is, how can we provide the required SSL object to the new process, so that it would start using the pre established secured session / channel? One possible solution I could think of is to use shared memory between the Server and new process. The server, before it exec the new process would create a copy of its SSL object in the shared memory and the new process then will use it. But I am not sure if such copying of SSL object is safe. Is there any other solution possible? Could someone guide me through this? Thank you, ~ UrjitDISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
SSL_read after SSL_Connect casues a problem
Hi List, it is me again. I first do SSL_connect. Tshark shows following: 0.004727 193.53.0.56 - 130.59.10.95 SSLv2 Client Hello 0.007715 130.59.10.95 - 193.53.0.56 TCP 7700 7700 [ACK] Seq=1 Ack=143 Win=6864 Len=0 TSV=2682067880 TSER=1368743865 0.042333 130.59.10.95 - 193.53.0.56 TCP [TCP segment of a reassembled PDU] 0.042432 130.59.10.95 - 193.53.0.56 TCP [TCP segment of a reassembled PDU] 0.042478 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=143 Ack=2897 Win=63712 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743865 TSER=2682067912 0.087649 130.59.10.95 - 193.53.0.56 TCP [TCP segment of a reassembled PDU] 0.088289 130.59.10.95 - 193.53.0.56 TCP [TCP segment of a reassembled PDU] 0.088408 130.59.10.95 - 193.53.0.56 TLSv1 Server Hello, Certificate, Server Key Exchange, Server Hello Done 0.089515 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=143 Ack=6914 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743865 TSER=2682067958 0.195570 193.53.0.56 - 130.59.10.95 TLSv1 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 0.225875 130.59.10.95 - 193.53.0.56 TLSv1 Change Cipher Spec 0.246038 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=333 Ack=6920 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743865 TSER=2682068098 0.249246 130.59.10.95 - 193.53.0.56 TLSv1 Encrypted Handshake Message 0.446155 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=333 Ack=6965 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743866 TSER=2682068121 0.777072 130.59.10.95 - 193.53.0.56 TLSv1 Application Data 0.846349 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=333 Ack=7002 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743866 TSER=2682068649 0.852923 130.59.10.95 - 193.53.0.56 TLSv1 Application Data 1.046481 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=333 Ack=8359 Win=65214 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743867 TSER=2682068721 It is, the per is sending application data after I connect. When I try, following happens: 1.777630 193.53.0.56 - 130.59.10.95 TLSv1 Client Hello 1.781125 130.59.10.95 - 193.53.0.56 TLSv1 Encrypted Alert 1.781129 130.59.10.95 - 193.53.0.56 TCP 7700 7700 [FIN, ACK] Seq=8388 Ack=465 Win=9008 Len=0 TSV=2682069653 TSER=1368743868 1.781221 193.53.0.56 - 130.59.10.95 TLSv1 Alert (Level: Fatal, Description: Unexpected Message), Alert (Level: Fatal, Description: Unexpected Message) This happens multiple times. Then 1.781245 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=1144 Ack=8389 Win=65222 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743868 TSER=2682069653 1.784479 130.59.10.95 - 193.53.0.56 TCP 7700 7700 [RST] Seq=8388 Len=0 1.784483 130.59.10.95 - 193.53.0.56 TCP 7700 7700 [RST] Seq=8389 Len=0 Do not care about TCP CHECKSUM INCORRECT, this is from tshark. So what is problem here ? Aarno __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
[SECURITY] OpenSSL 0.9.8d and 0.9.7l released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 0.9.8d and 0.9.7l released == OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8d of our open source toolkit for SSL/TLS. This new OpenSSL version is a security and bugfix release and incorporates changes and bugfixes to the toolkit. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES. This release fixes four security vulnerabilities, CVE-2006-2937, CVE-2006-2940, CVE-2006-3738, CVE-2006-4343. Please see http://www.openssl.org/news/secadv_20060928.txt We also release 0.9.7l, which contains the security update and bugfixes compared to 0.9.7k. We consider OpenSSL 0.9.8d to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.8d is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ For those who want or have to stay with the 0.9.7 series of OpenSSL, we strongly recommend that you upgrade to OpenSSL 0.9.7l as soon as possible. It's available in the same location as 0.9.8d. The distribution file names are: o openssl-0.9.8d.tar.gz MD5 checksum: 8ed1853538e1d05a1f5ada61ebf8bffa SHA1 checksum: 4136fba00303a3d319d2052bfa8e1f09a2e12fc2 o openssl-0.9.7l.tar.gz MD5 checksum: b21d6e10817ddeccf5fbe1379987333e SHA1 checksum: f0e4136639b10cbd1227c4f7350ff7ad406e575d The checksums were calculated using the following commands: openssl md5 openssl-0.9.*.tar.gz openssl sha1 openssl-0.9.*.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Nils Larsch Ulf Möller Ralf S. Engelschall Ben Laurie Andy Polyakov Dr. Stephen Henson Richard Levitte Geoff Thorpe Lutz JänickeBodo Möller -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iQCVAwUBRRvCTe6tTP1JpWPZAQIRbgP/aIb5s19eiSBrdGpSy36Ce1piAtBfqPPM Bw/j9Y6fWTQYS5z/ZNDnFLmbQw269bR5nYIMT6da5dyKmSt9v6dUJHdQXI7i/gf4 o3JPEZwqRqqz1tyhhBNFMNAx3hV73noLOXUUuak+2Zw9VtKGTb4HoRGGmXq8VUSn zeeX2KgXEwg= =fiHy -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Seeding the OpenSSL PRNG
Thanks all for your valuable comments, Erik Leunissen. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Seeding the OpenSSL PRNG (continued ...)
Apparently, there are some situations where there is no entropy source to seed the OpenSSL PRNG. Is there a uniform way to detect that the OpenSSL PRNG has not been seeded? Uniform is uniform over the various platforms because I want to prevent that I need to check on a per platform basis whether an entropy source is lacking. Erik Leunissen. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: linux-elf-arm configuration option missing
Thanks for the pointer Dr.Steve. Regards Yugandhar At 03:49 PM 9/28/2006, you wrote: On Thu, Sep 28, 2006, Yugandhar wrote: Hi, I am currently using OpenSSL 0.9.7e which has the option linux-elf-arm for ARM processors.Recently i downloaded OpenSSL 0.9.8c.It seems that the linux-elf-arm option has been removed from the Configure file. Can anyone throw some light on why this option has been removed.I want to use the OpenSSL library as a shared one on IXP425 based platform? Is there an equivalent option for linux-elf-arm? Any help is greatly appreciated. That and several others have been replaced by a linux-generic32 target. Depending on the byte sex of the OS you can also use -DB_ENDIAN of -DL_ENDIAN for example: perl Configure linux-generic32 -DB_ENDIAN Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Seeding the OpenSSL PRNG (continued ...)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik Leunissen Sent: Thursday, September 28, 2006 10:25 AM To: openssl-users@openssl.org Subject: Re: Seeding the OpenSSL PRNG (continued ...) Apparently, there are some situations where there is no entropy source to seed the OpenSSL PRNG. Is there a uniform way to detect that the OpenSSL PRNG has not been seeded? Uniform is uniform over the various platforms because I want to prevent that I need to check on a per platform basis whether an entropy source is lacking. I believe the function you want is RAND_status(). -- Adam Mlodzinski __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: SSL_read after SSL_Connect casues a problem
Hello, I first do SSL_connect. Tshark shows following: 0.004727 193.53.0.56 - 130.59.10.95 SSLv2 Client Hello 0.007715 130.59.10.95 - 193.53.0.56 TCP 7700 7700 [ACK] Seq=1 Ack=143 Win=6864 Len=0 TSV=2682067880 TSER=1368743865 0.042333 130.59.10.95 - 193.53.0.56 TCP [TCP segment of a reassembled PDU] 0.042432 130.59.10.95 - 193.53.0.56 TCP [TCP segment of a reassembled PDU] 0.042478 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=143 Ack=2897 Win=63712 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743865 TSER=2682067912 0.087649 130.59.10.95 - 193.53.0.56 TCP [TCP segment of a reassembled PDU] 0.088289 130.59.10.95 - 193.53.0.56 TCP [TCP segment of a reassembled PDU] 0.088408 130.59.10.95 - 193.53.0.56 TLSv1 Server Hello, Certificate, Server Key Exchange, Server Hello Done 0.089515 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=143 Ack=6914 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743865 TSER=2682067958 0.195570 193.53.0.56 - 130.59.10.95 TLSv1 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message Here we have end of client handshake packets: - Client Key Exchange - Change Cipher Spec (from now, all comunication to server will be encrypted) - Encrypted Handshake Message - probably client Finished packet, but this packet is encrypted and we know only that this packet belongs to handshake protocol 0.225875 130.59.10.95 - 193.53.0.56 TLSv1 Change Cipher Spec 0.246038 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=333 Ack=6920 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743865 TSER=2682068098 0.249246 130.59.10.95 - 193.53.0.56 TLSv1 Encrypted Handshake Message Here we have end of server handshake packets: - Change Cipher Spec (from now, all comunication to client will be encrypted) - Encrypted Handshake Message - probably server Finished packet, but this packet is encrypted and we know only that this packet belongs to handshake protocol 0.446155 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=333 Ack=6965 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743866 TSER=2682068121 0.777072 130.59.10.95 - 193.53.0.56 TLSv1 Application Data 0.846349 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=333 Ack=7002 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743866 TSER=2682068649 0.852923 130.59.10.95 - 193.53.0.56 TLSv1 Application Data 1.046481 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=333 Ack=8359 Win=65214 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743867 TSER=2682068721 Two encrypted application data packets from server. It is, the per is sending application data after I connect. When I try, following happens: 1.777630 193.53.0.56 - 130.59.10.95 TLSv1 Client Hello 1.781125 130.59.10.95 - 193.53.0.56 TLSv1 Encrypted Alert 1.781129 130.59.10.95 - 193.53.0.56 TCP 7700 7700 [FIN, ACK] Seq=8388 Ack=465 Win=9008 Len=0 TSV=2682069653 TSER=1368743868 1.781221 193.53.0.56 - 130.59.10.95 TLSv1 Alert (Level: Fatal, Description: Unexpected Message), Alert (Level: Fatal, Description: Unexpected Message) This looks like your client tries to do second handshake, this is not re-handshake (renegotiation) because when renegotiation is performed packets are encrypted and we may see only something like Encrypted Handshake Message, not Client Hello. For me this looks like you are using one context for SSL_connect() and other for SSL_read(). When SSL_read() is performed on SSL object created from SSL_CTX which is created with client method, auto-SSL_connect() is performed on unconnected SSL object when SSL_read()/SSL_write() is called. Check this. This happens multiple times. Then 1.781245 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=1144 Ack=8389 Win=65222 [TCP CHECKSUM INCORRECT] Len=0 TSV=1368743868 TSER=2682069653 1.784479 130.59.10.95 - 193.53.0.56 TCP 7700 7700 [RST] Seq=8388 Len=0 1.784483 130.59.10.95 - 193.53.0.56 TCP 7700 7700 [RST] Seq=8389 Len=0 Server reset connection. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Newbie Needs Help!!!
Hello, When I do that, I now get: RAPTOR_$ openssl s_client -connect adtest:636 -CAfile certnew.pem CONNECTED(0003) depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=27:certificate not trusted verify return:1 depth=0 /CN=adtest.altdomain2000.psccos.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=adtest.altdomain2000.psccos.com i:/C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca Get server certificate (lets say server_cert.pem) and execute: $ openssl verify -CAfile certnew.pem server_cert.pem if this will return success, s_client will verify successfully this server cert too. Next information, certnew.pem should have CA cert from: C=US/ST=CO/L=Colorado Springs/O=Process Software/CN=homeca Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
0.9.8d configure overrides -march=; any workaround?
In building the new release I noticed lots of these: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -march=pentium4 -mcpu=pentium -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -c -o mem_clr.o mem_clr.c `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead. Note that I did in fact specify -march=pentium4, but config has its own ideas about what kind of CPU I have and appended -mcpu=pentium. The code in config is really too simple. Unless developers want to enter the Red Queen's Race and maintain an ever-expanding and probably fragile block of code to winkle out the precise CPU specification for dozens of models, several brands, and various versions of GCC it is probably better to just punt this decision to the builder. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is intuitive he means the exact opposite. pgp1Xi1tjl9jC.pgp Description: PGP signature
Re: Seeding the OpenSSL PRNG (continued ...)
Erik Leunissen wrote: Is there a uniform way to detect that the OpenSSL PRNG has not been seeded? Uniform is uniform over the various platforms because I want Call RAND_status() (see http://www.openssl.org/docs/crypto/RAND_add.html#). Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Verifying Client-side Certificate?
How does on use OpenSSL on the server to verify a client-side SSL cert? Any examples of this?~RMC
Re: Verifying Client-side Certificate?
Richard Conlan wrote: How does on use OpenSSL on the server to verify a client-side SSL cert? Any examples of this? ~RMC Have you had a look at http://www.opensslbook.com/code.html? IIRC there is such an example... Hope it helps. Ted ;) smime.p7s Description: S/MIME Cryptographic Signature
OpenSSL-fips-1.0.tar.gz found here.
Although the source code does not seem to be available at http://www.oss-institute.org/ or www.openssl.org, it was still available, as of Sept 28 12:40pm CST US, on this Australian site. http://www2.psy.uq.edu.au/~ftp/Crypto/OpenSSL/ C Barker smime.p7s Description: S/MIME cryptographic signature
Re: Seeding the OpenSSL PRNG (continued ...)
Richard Koenning wrote: Call RAND_status() (see http://www.openssl.org/docs/crypto/RAND_add.html#). Right. I overlooked that one. Thanks, Erik. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
rewriting Subject to make O=CN?
I'd like to make the O equal to the CN while sign the CSR. For example, if the Subject was C=US, O=Example Company, CN=www.example.com, I'd like to issue a cert with C=Us, O=www.exmaple.com, CN=www.example.com. I searched man pages and configuration options, but couldn't figure it out. Any help would appreciated. Thanks. --IJ -- The New Internet2 Network. Smarter and Faster. Again. www.internet2.edu/network __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
