SSL error no start line
HI, what would error OpenSSL: error:0906D06C:PEM routines:PEM_read_bio:no start line mean ? Aarno __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL shutdown
Hi List, I have problem with SSL_shutdown. Advice seems to be to call it again, if the return value is 0. However, this means that shutdown can hang forever. Can I just call SSL_shutdown and go on ? regards aarno __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to implement HTTP authentication,does SSL implement this
Hi, implementing http over sl would mean implementing https, a separate thing. HTTP Basic and Digest authentications are part of HTTP itself. Btw, they are not meant to be very secure, but could be used for privact reasons. Aarno On 16 Oct 2006, at 07:20, bhanu_rao wrote: Hi all, I want to implement HTTP Authentication using C, so i want to know that does SSL has any function for implementing HTTP authentication 1.1 or it is not related to SSL , and if it implement it then want to know which are those function, Also can any one tell me how to test error codes and implement HTTP Authentication 1.1 by using C language I have find it in JAVA but doesnt know how to do it in C Thanks in advance Bhanu -- View this message in context: http://www.nabble.com/How-to- implement-HTTP-authentication%2Cdoes-SSL-implement-this- tf2449986.html#a6828638 Sent from the OpenSSL - User mailing list archive at Nabble.com. __ 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: SSL_read after SSL_Connect casues a problem
Hi Marek, thank you for the hint. There was a bug in setting up SSL socket. Aarno On 28 Sep 2006, at 16:58, Marek Marcola wrote: 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] __ 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: 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_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]
Strange problem with SSL_write
Hi List, I am implementing EPP over SSL. It requires me send send hex data (the length of the xml document). In addition, making EPP request twice is an error. So it differs http with both these counts. Then the problem: when i am doing SSL_write, it does return full length of the packet i send, but ethereal shows *two* application level packets. The packet indedd contains 0x00s. Can this be a problem ? Aarno __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Strange problem with SSL_write
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, Encrypted Handshake Message 72664.663229 130.59.10.95 - 193.53.0.56 TLSv1 [TCP Retransmission] Change Cipher Spec 72664.663315 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=2996013492 Ack=106323221 Win=65535 Len=0 TSV=1368546305 TSER=2583245740 72664.665924 130.59.10.95 - 193.53.0.56 TLSv1 [TCP Retransmission] Encrypted Handshake Message 72664.665956 193.53.0.56 - 130.59.10.95 TCP 7700 7700 [ACK] Seq=2996013492 Ack=106323266 Win=65535 Len=0 TSV=1368546305 TSER=2583245742 72664.675862 193.53.0.56 - 130.59.10.95 TLSv1 [TCP Retransmission] Application Data, Application Data this after one call of SSL_write. As you see, SSL is transmitting two separate application data packets. . The packet indedd contains 0x00s. Can this be a problem ? Are you trying to manually decrypt the data? Why do you care what bytes the packets contain? You shouldn't be looking at the TCP level except to diagnose a problem at the SSL level. Do you have a problem? The problem is having two application data packets, when i call SSL_write only once. 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. As for 0x00, this one is the cwise end-of-the- string. Some application have separate function call for handling date containing it.. Aarno __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Duplicate Posts
Roger F. Borrello, Jr. wrote: Am I the only one getting 4 or 5 copies of posted messages? No, I have the same problem. Aarno __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Kannel and Openssl
Hi, Vadim Fedukovich wrote: On Mon, 4 Mar 2002, Wilhelm Farrugia wrote: I am trying to use openssl with kannel are there any implications that I should know about? Does any one has some details about the issue ? Thank you, Wilhelm Farrugia Oleg Taranov did something with kannel and openssl and release it. Hope a search engine could help Kannel can now use https (using openssl, of course). See http://www.kannel; 3glab.org for details. You must use CVS version, and consult CVS documenta- tion, though. Aarno __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
