Re: How to port for Palm
Ian Goldberg did some work as part of TopGun (this is a rather outdated port though): http://www.isaac.cs.berkeley.edu/pilot/ Also, Palm OS 5.0 is supposed to ship with an SSL library. nagendra * mohanraj venkatesh kumar <[EMAIL PROTECTED]> [2002-11-27 16:27:54 +]: > Dear Sir, > > Iam trying to port OpenSSL to Palm. Iam trying to develop a client side > application that would use SSL. > > Could someone please guide me as what are the common files that I would > need to take as-is and what are the files that need to be ported for a > particular OS(Palm OS). > > Thanks in advance. > > Venkatesh > > > > _ > STOP MORE SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail > __ > 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]
minor bug in ssl3_send_certificate_request()
In function ssl3_send_certificate_request(), the state is never switched to SSL3_ST_SW_CERT_REQ_B after the handshake message is serialized. It's a fairly minor bug, with a simple fix: #ifdef NETSCAPE_HANG_BUG p=(unsigned char *)s->init_buf->data + s->init_num; /* do the header */ *(p++)=SSL3_MT_SERVER_DONE; *(p++)=0; *(p++)=0; *(p++)=0; s->init_num += 4; #endif > > s->state = SSL3_ST_SW_CERT_REQ_B; } /* SSL3_ST_SW_CERT_REQ_B */ return(ssl3_do_write(s,SSL3_RT_HANDSHAKE)); err: return(-1); } __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
rsync://dev.openssl.org unavailable?
Is rsync access to the OpenSSL repository unavailable? $ rsync://dev.openssl.org/ rsync: failed to connect to dev.openssl.org: Connection refused rsync error: error in socket IO (code 10) at /SourceCache/rsync/rsync-14/rsync/clientserver.c(93) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
rsync://dev.openssl.org busy?
I've been trying to access the OpenSSL CVS repository for the past couple of days (including odd hours), with no success: $ rsync rsync://dev.openssl.org/openssl-cvs @ERROR: max connections (20) reached - try again later rsync: connection unexpectedly closed (0 bytes received so far) [receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(359) Any thoughts? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: rsync://dev.openssl.org busy?
> Please try again now. It should be available again. Thanks for looking into it, works now. nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Datagram TLS source
Datagram TLS (DTLS) source is now part of the OpenSSL repository (CVS main branch). Also, I have seperately released patches against openssl-0.9.7g. This is the link to the main DTLS page (including links to further information about the protocol, and patches): http://crypto.stanford.edu/~nagendra/projects/dtls/ I am in the process of putting together an FAQ, so any questions/comments you may have will be much appreciated. Thanks, nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Datagram TLS source
* Prashant Kumar <[EMAIL PROTECTED]> [2005-04-28 06:11:38 -0700]: > I had one question on the timer management and retransmission. I see that > there is a new BIO type in the file bss_dgram.c. My question is if the > application does not use the dgram BIO type and use the memory BIO instead, > does the application has to take the responsibility of timer management and > retransmission ? If you are using a memory BIO for doing I/O, then you are also using DTLS in non-blocking mode -- in this case, the application is responsible for managing timeouts. When a timer expires, the application calls SSL_read() / SSL_write(), and the DTLS layer will take care of retransmitting. You may want to look at resiprocate/sip/resiprocate/DtlsTransport.cxx for an implementation of something very similar to the scenario you describe. On a high level, reSIProcate does the following: 1) many DTLS sessions use the same file descriptor for network I/O. 2) after data is read from the network, data is passed to the appropriate DTLS session (based on remote IP address & port number) through a mem BIO. nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: pqueue needs some rethinking...
Ah, I see. The reason pqueue uses 64-bit integers as the priority type is that record sequence numbers are 64-bits. I can easily change the code to make use of a pair of 32-bit integers (given that this really isn't performance critical code). nagendra * Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> [2005-04-30 15:16:26 +0200]: > Hi, > > We need to rethink pqueue a little bit. The trouble with it right now > is that it uses BN_ULLONG in the published API. Unfortunately, > BN_ULLONG doesn't work on all platforms we (pretend to?) support. > > In the BIGNUM code, all uses of BN_LLONG and BN_ULLONG are wrapped in > a check for BN_LLONG. This macro is undefined on VMS (see the > beginning of bn.h) for a very good reason; On VMS for VAX, there is no > (or has not been until very recently) 64-bit integer type that's > easily reachable from C (see > http://h71000.www7.hp.com/commercial/c/docs/6180p006.html#integral_types_sec). > This is actually rather silly, since the VAX does have the quad type, > but apparently that was nothing for C... > > Anyway, this means that pqueue very simply breaks on VMS for VAX, > because the definition of BN_ULLONG becomes 'unsigned long long', > which isn't a supported type. > > I know next to nothing about DTLS, so I'm not sure if the priority > field really has to be such a large number. Can it be easily changed? > > Either way, this will be a show stopper for the upcoming release of > OpenSSL 0.9.8 (see http://www.oenssl.org/news/state.html). > > Cheers, > Richard > > - > Please consider sponsoring my work on free software. > See http://www.free.lp.se/sponsoring.html for details. > > -- > Richard Levitte [EMAIL PROTECTED] > http://richard.levitte.org/ > > "When I became a man I put away childish things, including > the fear of childishness and the desire to be very grown up." > -- C.S. Lewis > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: DTLS & OpenSsl9.7g, assertion with mutual auth.
I was able to replicate the bug and have attached an
incremental patch--mutual auth should work now. Let me know
how it goes. Thanks,
nagendra
* Prashant Kumar <[EMAIL PROTECTED]> [2005-05-09 14:03:21 -0700]:
> Hello Nagendra,
>
> I tried your DTLS patch with Openssl9.7g on a vxworks platform. Everything
> works except mutual certificate authentication. When I enable mutual
> certificate authentication, DTLS fails with the following assertion:
>
> d1_both.c(1054): OpenSSL internal error, assertion failed:
> s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH == s->init_num
>
> I tried the same thing on a Linux platform and got the same error.
>
> Here is the debug info for the lengths:
> s->init_num = 19
> w_msg_hdr.msg_len = 393
>
> Thank you so much for your help.
>
> Regards,
> Prashant.
>
>
> Prashant Kumar <[EMAIL PROTECTED]> wrote:Hello Nagendra,
>
> I had one question on the timer management and retransmission. I see that
> there is a new BIO type in the file bss_dgram.c. My question is if the
> application does not use the dgram BIO type and use the memory BIO instead,
> does the application has to take the responsibility of timer management and
> retransmission ?
>
> Thanks you,
> Prashant Kumar.
>
> nagendra modadugu <[EMAIL PROTECTED]> wrote:
>
> Datagram TLS (DTLS) source is now part of the OpenSSL
> repository (CVS main branch). Also, I have seperately released
> patches against openssl-0.9.7g.
>
> This is the link to the main DTLS page (including links
> to further information about the protocol, and patches):
>
> http://crypto.stanford.edu/~nagendra/projects/dtls/
>
> I am in the process of putting together an FAQ, so any
> questions/comments you may have will be much appreciated.
> Thanks,
>
> nagendra
>
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@openssl.org
> Automated List Manager [EMAIL PROTECTED]
>
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.c om
>
>
>
> -
> Yahoo! Mail
> Stay connected, organized, and protected. Take the tour
--- openssl-0.9.7g/ssl/d1_srvr.c2005-05-10 00:32:27.0 -0700
+++ openssl-0.9.7g-bugfixing/ssl/d1_srvr.c 2005-05-10 00:27:21.0
-0700
@@ -1018,6 +1018,7 @@
STACK_OF(X509_NAME) *sk=NULL;
X509_NAME *name;
BUF_MEM *buf;
+ unsigned int msg_len;
if (s->state == SSL3_ST_SW_CERT_REQ_A)
{
@@ -1094,7 +1095,10 @@
s->init_num += 4;
#endif
- /* XDTLS: set message header ? */
+ msg_len = s->init_num - DTLS1_HM_HEADER_LENGTH;
+ dtls1_set_message_header(s, s->init_buf->data,
+ SSL3_MT_CERTIFICATE_REQUEST, msg_len, 0, msg_len);
+
/* buffer the message to handle re-xmits */
dtls1_buffer_message(s, 0);
Re: [CVS] OpenSSL: openssl/ FAQ
Apologies for the delayed joining of the discussion. I chose to use BN to implement 64-bit numbers because (1) it was little code, (2) the abstraction was clean, (3) BN works on all supported platforms, (4) the places where emulated 64-bit numbers are used are not performance critical, and (5) no changes were required outside of pqueue and DTLS code. > appro> 1. I'm reluctant to include bn.h to non-bn code, because it's > appro>nothing but counterintuitive [and is not good in long run]. > appro> 2. My standpoint is [still] that pqueue/dtls1 should not have > appro>dependancy on bh.h either. I don't quite follow this point. Is it that pqueue is not self-contained? (There are already a number of cross-dependancies in libcrypto, including on bn.h) > appro> 3. Using BIGNUM for DTLS purposes is *total* overkill. To back > appro>this up I'm going to suggest alternative, 64-bit neutral pq > appro>code shortly:-) That works for me. Though, I'll add that neither pqueue nor DTLS do anything heavy with PQ_64BIT--the performance gain for the few platforms that do need the specialized code will be minimal. nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1105] DTLS HelloVerifyRequest PATCH
I think you might have found a bug in the draft document. I'll get back
to you soon. Thanks,
nagendra
* Tigran Gevorgyan via RT <[EMAIL PROTECTED]> [2005-06-08 22:00:58 +0200]:
>
>
> Hello,
> I apologize if this message appears multiple times.
>
> This is a proposed patch for openssl-0.9.8-beta for all platforms.
> I tested it with openssl-0.9.8beta2 however I think it is applicable to
> all openssl-0.9.8 trees.
>
>
>I think the current implementation of DTLS is not compliant with the
> draft. According to
> http://www.ietf.org/internet-drafts/draft-rescorla-dtls-04.txt Section
> 4.3 the HelloVerifyRequest is defined like this:
>
> struct {
>Cookie cookie<0..32>;
> } HelloVerifyRequest;
>
> The 0.9.8-beta2 implementation has two additional octets which specify
> the protocol version. Is this according to a newer version of the DTLS
> draft or is it an error?
> Attached is a patch that removes the code that parses and generates this
> additional octets.
>
> Thanks
>Tigran Gevorgyan
>
>
>
>
>
>
>
> This e-mail message, including any attachments, is for the sole use of the
> intended recipient(s) and may contain confidential and privileged
> information. Unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please contact the sender
> by reply e-mail and destroy all copies of the original message. Thank you.
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@openssl.org
> Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1105] DTLS HelloVerifyRequest PATCH
It turns out that the Version field was omitted from the
HelloVerify message in the internet draft. The document
will be corrected.
nagendra
* nagendra modadugu <[EMAIL PROTECTED]> [2005-06-08 17:09:40 -0700]:
>
> I think you might have found a bug in the draft document. I'll get back
> to you soon. Thanks,
>
> nagendra
>
> * Tigran Gevorgyan via RT <[EMAIL PROTECTED]> [2005-06-08 22:00:58 +0200]:
>
> >
> >
> > Hello,
> > I apologize if this message appears multiple times.
> >
> > This is a proposed patch for openssl-0.9.8-beta for all platforms.
> > I tested it with openssl-0.9.8beta2 however I think it is applicable to
> > all openssl-0.9.8 trees.
> >
> >
> >I think the current implementation of DTLS is not compliant with the
> > draft. According to
> > http://www.ietf.org/internet-drafts/draft-rescorla-dtls-04.txt Section
> > 4.3 the HelloVerifyRequest is defined like this:
> >
> > struct {
> >Cookie cookie<0..32>;
> > } HelloVerifyRequest;
> >
> > The 0.9.8-beta2 implementation has two additional octets which specify
> > the protocol version. Is this according to a newer version of the DTLS
> > draft or is it an error?
> > Attached is a patch that removes the code that parses and generates this
> > additional octets.
> >
> > Thanks
> >Tigran Gevorgyan
> >
> >
> >
> >
> >
> >
> >
> > This e-mail message, including any attachments, is for the sole use of the
> > intended recipient(s) and may contain confidential and privileged
> > information. Unauthorized review, use, disclosure or distribution is
> > prohibited. If you are not the intended recipient, please contact the
> > sender by reply e-mail and destroy all copies of the original message.
> > Thank you.
> > __
> > OpenSSL Project http://www.openssl.org
> > Development Mailing List openssl-dev@openssl.org
> > Automated List Manager [EMAIL PROTECTED]
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@openssl.org
> Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1105] DTLS HelloVerifyRequest PATCH
> So the bug report can be removed, right? Yes, the report can be removed. It is not a bug. > (and *please* keep [EMAIL PROTECTED] among the recipients. It's quite > hard to follow history in the database when people keep skipping that > address) Apologies. nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
inconsistent behaviour on openssl ciphers
With OpenSSL 0.9.8a: $ openssl version OpenSSL 0.9.8a 11 Oct 2005 $ openssl ciphers 'RSA+DSS+AES+3DES+SHA1' Error in cipher list 15676:error:144020B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl_lib.c:1176: With OpenSSL 0.9.7d: $ openssl version OpenSSL 0.9.7d 17 Mar 2004 $ openssl ciphers 'RSA+DSS+AES+3DES+SHA1' AES256-SHA:AES128-SHA:DES-CBC3-SHA Did the cipherspec format change between 0.9.7 and 0.9.8? Thanks, nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[PATCH] bug in crypto/pqueue/pqueue.c
diff -u -r1.5 pqueue.c --- crypto/pqueue/pqueue.c 7 Jun 2005 22:21:14 - 1.5 +++ crypto/pqueue/pqueue.c 20 Dec 2005 01:48:27 - @@ -184,7 +184,7 @@ } /* check the one last node */ - if ( memcpy(next->priority, prio64be,8) ==0) + if ( memcmp(next->priority, prio64be,8) ==0) found = next; if ( ! found) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: DTLS & OpenSSL0.9.8a, assertion with mutual auth.
> He told me that this patch must be in the upstream openssl cvs. > Why is this patch not an official release or directly applied to the cvs? Manuel, you're right. This patch missed the last release. I'm in the process of submitting some patches to openssl-cvs and will include this patch. I'll send mail once the patches have been accepted, most likely within the following week. nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
bug in ssl3_get_key_exchange
SSLv3 clients call ssl3_get_key_exchange regardless of whether this message is required for the chosen cipher. As a result, ssl3_get_message called from ssl3_get_key_exchange ends up reading the certificate request message (when doing client auth and the key exchange message is absent): n=ssl3_get_message(s, SSL3_ST_CR_KEY_EXCH_A, SSL3_ST_CR_KEY_EXCH_B, -1, 1024*8, /* ?? */ &ok); This results in a limit of 8K for the certificate request list, whereas the limit should be 100K. This bug manifests itself when using s_client to connect to apache-modssl. Apache sends all the CA's listed in ca-bundle.crt, which exceeds the 8K limit and causes the client to barf: 28537:error:1408E098:SSL routines:SSL3_GET_MESSAGE:excessive message size:s3_both.c:418: Nagendra Modadugu [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
info regarding SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER
I've looked around the web and openssl-dev archives, but am unable to find information about SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER and the related Microsoft "bug" that results in jumbo SSL records. Does anyone have pointers / information about this bug ? Thanks. nagendra -=-=-=-=-=-=-=-=-=-=-=-= Nagendra Modadugu nagendra @ cs.stanford.edu __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
a handful of performance related patches
I am writing to advertise three performance related openssl patches: handshake_cutthrough.patch Enables SSL3+ clients to send application data immediately following the Finished message even when negotiating full-handshakes. With this patch, clients can negotiate SSL connections in 1-RTT even when performing full-handshakes. rsaasync.patch Enable RSA private decrypt operations to be non-blocking, thus allowing RSA private decrypt operations to be carried out in other threads or processes. small_records.patch Reduce OpenSSL memory consumption. SSL records may be as large as 16K, but are typically < 2K. In addition, a historic bug in Windows allowed records to be as large 32K. OpenSSL statically allocates read and write buffers (34K and 18K respectively) used for processing records. With this patch, OpenSSL statically allocates 4K + 4K buffers, with the option of dynamically growing buffers to 34K + 4K, which is a saving of 44K per connection for the typical case. The patches are available here: http://bazaar.launchpad.net/~nagendra/openssl-patches/trunk/files __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
