Re: Google summer of code?
On Sun, 2009-02-22 at 19:51 +0200, Billy Brumley wrote: Hi--hopefully this is the correct list. Is there any chance of openssl participating as a mentor organization for Google summer of code? I will also be very interested! bye! -- Emanuele Cesena emanuele.ces...@gmail.com http://ecesena.dyndns.org Il corpo non ha ideali __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Google summer of code?
Perhaps I should be more detailed ;) I'm interested in providing Koblitz curve specific functionality to the elliptic curve portion of OpenSSL--they are currently treated as regular binary curves. All point doublings can be replaced by a simpler operation called the Frobenius map, leading to quite a speed improvement. I implemented a prototype for this, some details are given in (p5, Tbl 2), signing and verifications see roughly a 50% speedup: http://www.tcs.hut.fi/Publications/bbrumley/pla_implicitcerts_2008.pdf The implementation currently lives outside of OpenSSL, so it should be properly integrated and tightened up; Koblitz curves should then call down to this specific scalar multiplication function, instead of the generic Montgomery's ladder currently used for binary curves. Textbook LD coordinates are also included in the implementation. If there is any interest in this kind of functionality, I'm hoping an OpenSSL developer would be willing to act as a mentor for me to do the work as part of Google summer of code. If so, please feel free to reply here or contact me directly for more detailed discussions. Billy billy.brumley at hut dot fi On Sun, Feb 22, 2009 at 7:51 PM, Billy Brumley bbrum...@gmail.com wrote: Hi--hopefully this is the correct list. Is there any chance of openssl participating as a mentor organization for Google summer of code? Best, Billy __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Google summer of code?
On Wed, 2009-02-25 at 11:44 +0200, Billy Brumley wrote: Perhaps I should be more detailed ;) I'm interested in providing Koblitz curve specific functionality to the elliptic curve portion of OpenSSL--they are currently treated as regular binary curves. All point doublings can be replaced by a simpler operation called the Frobenius map, leading to quite a speed improvement. Cool! I have a bit of experience on this too: http://caccioppoli.mac.rub.de/website/papers/tzv2.pdf So I could be interested in this topic (if working in more than one person is allowed). Other interesting topics (in my order of preference) could be: 1. Pairing-based cryptography, at least Barreto-Naerigh curves (currently I added a BN curve and use OpenSSL for scalar multiplications, but I use a Miracl-based engine to compute pairing) 2. Direct Anonymous Attestation protocol (I have a several piece of code: generic DAA, DAA with TPM, DAA with BN curves, DAA extension to TLS) 3. Trace Zero Varieties (cf. the above paper). They are faster than ECC but, unfortunately, not standardized... so maybe this only would fit in an experimental branch and is not actually useful. bye! -- Emanuele Cesena emanuele.ces...@gmail.com http://ecesena.dyndns.org Il corpo non ha ideali __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Google summer of code?
On Wed, 2009-02-25 at 10:29 +0100, Emanuele Cesena wrote: On Sun, 2009-02-22 at 19:51 +0200, Billy Brumley wrote: Hi--hopefully this is the correct list. Is there any chance of openssl participating as a mentor organization for Google summer of code? I will also be very interested! I am also interested. Has OpenSSL ever participated to the google's summer of code? Anyone would be interested in doing so? -- Davide __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Support DTLS compatibility with Cisco AnyConnect VPN [openssl.org #1751]
On Mon, 2009-02-09 at 07:14 +, David Woodhouse wrote: On Sun, 2009-01-11 at 10:47 +, David Woodhouse wrote: On Sat, 2008-12-20 at 14:00 +0100, David Woodhouse via RT wrote: On Tue, 2008-10-07 at 10:12 +0100, David Woodhouse wrote: This patch against the 0.9.8 branch adds an SSL option for compatibility with the pre-RFC version of DTLS used by Cisco for their AnyConnect SSL VPN. This is RT #1751. With this patch, and with the two bug fixes I just posted, I now have a fully functional client operating with Cisco's VPN servers. Leaving aside the question of adding this to HEAD, can we please at least add it to the 0.9.8 branch? We're shipping a completely functional client for this VPN now, and all that remains is to get the pre-RFC version of DTLS working again, which is implemented by this patch. Hello? We really need to be able to communicate with the older versions of OpenSSL which are out there in production use. Ping? Hello? Is there anybody out there? -- dwmw2 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1751] [PATCH] Support DTLS compatibility with Cisco AnyConnect VPN
[dw...@infradead.org - Sat Dec 20 14:00:34 2008]: On Tue, 2008-10-07 at 10:12 +0100, David Woodhouse wrote: This patch against the 0.9.8 branch adds an SSL option for compatibility with the pre-RFC version of DTLS used by Cisco for their AnyConnect SSL VPN. This is RT #1751. With this patch, and with the two bug fixes I just posted, I now have a fully functional client operating with Cisco's VPN servers. Leaving aside the question of adding this to HEAD, can we please at least add it to the 0.9.8 branch? Adding to HEAD seems less problematic. Anyway, I'm mostly happy with this patch, except from d1_pkt.c, shouldn't: if (s-client_version == DTLS1_BAD_VER || s-version == DTLS1_BAD_VER) ccs_hdr_len = 3; be if (s-client_version == DTLS1_BAD_VER || (s-options SSL_OP_CISCO_ANYCONNECT)) ccs_hdr_len = 3; also, the patch as an attachment would be nice. We're shipping a completely functional client for this VPN now, and all that remains is to get the pre-RFC version of DTLS working again, which is implemented by this patch. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1828] [PATCH] DTLS Retransmission Bug
Unfortunately the problem was way more severe than I expected:
This patch solves four issues now. At first the index of the
retransmission queue is the message sequence number bitwise ORed with
the current epoch. The epoch cannot be used to retrieve the buffered
messages because it could have changed until a retransmission has to
be done and is therefor not necessarily known. Since there can only be
one handshake at a time, every message can only be once in the queue
so the epoch can be removed. The message sequence number alone is not
sufficient, because the ChangeCipherSpec doesn't have one, so it will
have the same index as the Finished. A solution is using the message
sequence number multiplied by 2 and if the message is a
ChangeCipherSpec 1 is subtraced. This has the advantage that the index
of the CCS is always one less than the Finished, so the order of the
indices is preserved, which is important in a priority queue and the
unsigned short sequence number variable can be kept.
The second issue is when the server's CCS/Finished flight got lost and
the client repeats its last flight, the server already left the
handshake. Because of the unexpected messages it will enter the
handshake again which fails because then a ClientHello is expected.
This can be solved by adding another condition for unexpected
messages. If a Finished is received with the current epoch, it only
can be a retransmission, so in that case the last flight of the server
is just repeated without entering the handshake routine.
The third issue is that retransmissions are performed with the current
session parameters, that is epoch, algorithms and mastersecret. This
fails if a ChangeCiperSpec got lost and handshake messages of the
previous epoch have to be repeated. As a solution the current state is
saved with the message in the retransmission queue, to be able to
restore it when a retransmission is necessary.
Additionally the sequence number of the record layer is now bound to
the epoch. Retransmissions of a previous epoch will reuse the sequence
number of that epoch instead of the current one (which has been reset
after sending the CCS). Otherwise there can be combinations which
already have been there and the peer will discard the messages in its
replay check.
--- ssl/d1_both.c 2007-10-17 23:17:49.0 +0200
+++ ssl/d1_both.c 2009-02-25 16:37:55.0 +0100
@@ -136,7 +136,6 @@
static void dtls1_set_message_header_int(SSL *s, unsigned char mt,
unsigned long len, unsigned short seq_num, unsigned long frag_off,
unsigned long frag_len);
-static int dtls1_retransmit_buffered_messages(SSL *s);
static long dtls1_get_message_fragment(SSL *s, int st1, int stn,
long max, int *ok);
@@ -943,7 +942,7 @@
}
-static int
+int
dtls1_retransmit_buffered_messages(SSL *s)
{
pqueue sent = s-d1-sent_messages;
@@ -957,8 +956,8 @@
for ( item = pqueue_next(iter); item != NULL; item =
pqueue_next(iter))
{
frag = (hm_fragment *)item-data;
- if ( dtls1_retransmit_message(s, frag-msg_header.seq, 0, found)
= 0
- found)
+ if ( dtls1_retransmit_message(s, frag-msg_header.seq * 2 - frag-
msg_header.is_ccs,
+ 0, found) = 0 found)
{
fprintf(stderr, dtls1_retransmit_message() failed\n);
return -1;
@@ -974,7 +973,6 @@
pitem *item;
hm_fragment *frag;
PQ_64BIT seq64;
- unsigned int epoch = s-d1-w_epoch;
/* this function is called immediately after a message has
* been serialized */
@@ -988,7 +986,6 @@
{
OPENSSL_assert(s-d1-w_msg_hdr.msg_len +
DTLS1_CCS_HEADER_LENGTH = (unsigned int)s-init_num);
- epoch++;
}
else
{
@@ -1003,8 +1000,24 @@
frag-msg_header.frag_len = s-d1-w_msg_hdr.msg_len;
frag-msg_header.is_ccs = is_ccs;
+ /* save current state*/
+ frag-msg_header.saved_retransmit_state.enc_write_ctx = s-
enc_write_ctx;
+ frag-msg_header.saved_retransmit_state.write_hash = s-write_hash;
+ frag-msg_header.saved_retransmit_state.compress = s-compress;
+ frag-msg_header.saved_retransmit_state.session = s-session;
+ frag-msg_header.saved_retransmit_state.epoch = s-d1-w_epoch;
+
pq_64bit_init(seq64);
- pq_64bit_assign_word(seq64, epoch16 | frag-msg_header.seq);
+
+ /* The index of the retransmission queue actually is the message
sequence number,
+ * since the queue only contains messages of a single handshake.
However, the
+ * ChangeCipherSpec has no message sequence number and so using only
the sequence
+ * will result in the CCS and Finished having the same index. To
prevent this,
+ * the sequence number is multiplied by 2. In case of a CCS 1
[openssl.org #1828] [PATCH] DTLS Retransmission Bug
Unfortunately the problem was way more severe than I expected:
This patch solves four issues now. At first the index of the
retransmission queue is the message sequence number bitwise ORed with
the current epoch. The epoch cannot be used to retrieve the buffered
messages because it could have changed until a retransmission has to
be done and is therefor not necessarily known. Since there can only be
one handshake at a time, every message can only be once in the queue
so the epoch can be removed. The message sequence number alone is not
sufficient, because the ChangeCipherSpec doesn't have one, so it will
have the same index as the Finished. A solution is using the message
sequence number multiplied by 2 and if the message is a
ChangeCipherSpec 1 is subtraced. This has the advantage that the index
of the CCS is always one less than the Finished, so the order of the
indices is preserved, which is important in a priority queue and the
unsigned short sequence number variable can be kept.
The second issue is when the server's CCS/Finished flight got lost and
the client repeats its last flight, the server already left the
handshake. Because of the unexpected messages it will enter the
handshake again which fails because then a ClientHello is expected.
This can be solved by adding another condition for unexpected
messages. If a Finished is received with the current epoch, it only
can be a retransmission, so in that case the last flight of the server
is just repeated without entering the handshake routine.
The third issue is that retransmissions are performed with the current
session parameters, that is epoch, algorithms and mastersecret. This
fails if a ChangeCiperSpec got lost and handshake messages of the
previous epoch have to be repeated. As a solution the current state is
saved with the message in the retransmission queue, to be able to
restore it when a retransmission is necessary.
Additionally the sequence number of the record layer is now bound to
the epoch. Retransmissions of a previous epoch will reuse the sequence
number of that epoch instead of the current one (which has been reset
after sending the CCS). Otherwise there can be combinations which
already have been there and the peer will discard the messages in its
replay check.
--- ssl/d1_both.c 2007-10-17 23:17:49.0 +0200
+++ ssl/d1_both.c 2009-02-25 16:37:55.0 +0100
@@ -136,7 +136,6 @@
static void dtls1_set_message_header_int(SSL *s, unsigned char mt,
unsigned long len, unsigned short seq_num, unsigned long frag_off,
unsigned long frag_len);
-static int dtls1_retransmit_buffered_messages(SSL *s);
static long dtls1_get_message_fragment(SSL *s, int st1, int stn,
long max, int *ok);
@@ -943,7 +942,7 @@
}
-static int
+int
dtls1_retransmit_buffered_messages(SSL *s)
{
pqueue sent = s-d1-sent_messages;
@@ -957,8 +956,8 @@
for ( item = pqueue_next(iter); item != NULL; item =
pqueue_next(iter))
{
frag = (hm_fragment *)item-data;
- if ( dtls1_retransmit_message(s, frag-msg_header.seq, 0,
found)
= 0
- found)
+ if ( dtls1_retransmit_message(s, frag-msg_header.seq * 2 -
frag-
msg_header.is_ccs,
+ 0, found) = 0 found)
{
fprintf(stderr, dtls1_retransmit_message() failed\n);
return -1;
@@ -974,7 +973,6 @@
pitem *item;
hm_fragment *frag;
PQ_64BIT seq64;
- unsigned int epoch = s-d1-w_epoch;
/* this function is called immediately after a message has
* been serialized */
@@ -988,7 +986,6 @@
{
OPENSSL_assert(s-d1-w_msg_hdr.msg_len +
DTLS1_CCS_HEADER_LENGTH = (unsigned int)s-init_num);
- epoch++;
}
else
{
@@ -1003,8 +1000,24 @@
frag-msg_header.frag_len = s-d1-w_msg_hdr.msg_len;
frag-msg_header.is_ccs = is_ccs;
+ /* save current state*/
+ frag-msg_header.saved_retransmit_state.enc_write_ctx = s-
enc_write_ctx;
+ frag-msg_header.saved_retransmit_state.write_hash = s-write_hash;
+ frag-msg_header.saved_retransmit_state.compress = s-compress;
+ frag-msg_header.saved_retransmit_state.session = s-session;
+ frag-msg_header.saved_retransmit_state.epoch = s-d1-w_epoch;
+
pq_64bit_init(seq64);
- pq_64bit_assign_word(seq64, epoch16 | frag-msg_header.seq);
+
+ /* The index of the retransmission queue actually is the message
sequence number,
+* since the queue only contains messages of a single handshake.
However, the
+* ChangeCipherSpec has no message sequence number and so using only
the sequence
+* will result in the CCS and Finished having the same index. To
prevent this,
+*
[openssl.org #1849] AIX build failure: Cannot find a rule to create target ../include/openssl/fips.h from dependencies
While trying to build the daily snaps from the period 02/01/2009 -
02/24/2009 on AIX I get the error:
Cannot find a rule to create target ../include/openssl/fips.h from
dependencies
I have not built the fips library and did not intend to at this time. Is
this a requirement now?
I don't think this actually has anything to do with the fips library not
being there but maybe? . . .
The last build I could complete on AIX was 0.9.8i.
0.9.8j had other issues on AIX which are fixed in the daily snaps but I
have not been able to build a daily since I started trying (early Feb).
I have the snaps from 02/01-02/05 and 02/23-02/24
Here are the commands and results:
*
dn_...@uxap025d$ ./Configure aix64-cc config.log
/home/dn_app/thirdparty/openssl/openssl-0.9.8-stable-SNAP-20090224
dn_...@uxap025d$ make make.log
ebcdic.c, line 221.7: 1506-356 (W) Compilation unit is empty.
make: 1254-004 The error code from the last command is 1.
Stop.
/home/dn_app/thirdparty/openssl/openssl-0.9.8-stable-SNAP-20090224
**
Here is the testlog from the make report command
**
OpenSSL self-test report:
OpenSSL version: 0.9.8k-dev
Last change: New -hex option for openssl rand
Options: no-camellia no-capieng no-cms no-gmp no-jpake no-krb5
no-mdc2 no-montasm no-rc5 no-rfc3779 no-seed no-shared no-zlib
no-zlib-dynamic
OS (uname): AIX uxap025d 3 5 00C73CCA4C00
OS (config): 00C73CCA4C00-ibm-aix
Target (default): aix-cc
Target: aix64-cc
Compiler:
Failure!
-
if [ -n ]; then EXCL_OBJ='aes_core.o aes_cbc.o aix_ppc64.o
des_enc.o fcrypt_b.o ../crypto/aes/aes_cfb.o ../crypto/aes/aes_ecb.o
../crypto/aes/aes_ofb.o ../crypto/bn/bn_add.o ../crypto/bn/bn_blind.o
../crypto/bn/bn_ctx.o ../crypto/bn/bn_div.o ../crypto/bn/bn_exp2.o
../crypto/bn/bn_exp.o ../crypto/bn/bn_gcd.o ../crypto/bn/bn_lib.o
../crypto/bn/bn_mod.o ../crypto/bn/bn_mont.o ../crypto/bn/bn_mul.o
../crypto/bn/bn_prime.o ../crypto/bn/bn_rand.o ../crypto/bn/bn_recp.o
../crypto/bn/bn_shift.o ../crypto/bn/bn_sqr.o ../crypto/bn/bn_word.o
../crypto/bn/bn_x931p.o ../crypto/buffer/buf_str.o
../crypto/cryptlib.o ../crypto/des/cfb64ede.o ../crypto/des/cfb64enc.o
../crypto/des/cfb_enc.o ../crypto/des/ecb3_enc.o
../crypto/des/ecb_enc.o ../crypto/des/ofb64ede.o
../crypto/des/ofb64enc.o ../crypto/des/fcrypt.o
../crypto/des/set_key.o ../crypto/dsa/dsa_utl.o
../crypto/dsa/dsa_sign.o ../crypto/dsa/dsa_vrf.o ../crypto/err/err.o
../crypto/evp/digest.o ../crypto/evp/enc_min.o ../crypto/evp/e_aes.o
../crypto/evp/e_des3.o ../crypto/evp/p_sign.o ../crypto/evp/p_verify.o
../crypto/mem_clr.o ../crypto/mem.o ../crypto/rand/md_rand.o
../crypto/rand/rand_egd.o ../crypto/rand/randfile.o
../crypto/rand/rand_lib.o ../crypto/rand/rand_os2.o
../crypto/rand/rand_unix.o ../crypto/rand/rand_win.o
../crypto/rsa/rsa_lib.o ../crypto/rsa/rsa_none.o
../crypto/rsa/rsa_oaep.o ../crypto/rsa/rsa_pk1.o
../crypto/rsa/rsa_pss.o ../crypto/rsa/rsa_ssl.o
../crypto/rsa/rsa_x931.o ../crypto/sha/sha1dgst.o
../crypto/sha/sha256.o ../crypto/sha/sha512.o ../crypto/uid.o' ;
export EXCL_OBJ ; ARX='/usr/bin/perl ${TOP}/util/arx.pl ar -X 64 r' ;
else ARX='ar -X 64 r' ; fi ; export ARX ; dir=crypto; target=all; if
echo crypto ssl engines apps test tools | grep $dir /dev/null
2/dev/null; then if [ -d $dir ]; then ([ $target != all -a -z
] FIPSCANLIB=/dev/null; cd $dir echo making $target in
$dir... TOP= unset TOP ${LIB+LIB} ${LIBS+LIBS}
${INCLUDE+INCLUDE} ${INCLUDES+INCLUDES} ${DIR+DIR} ${DIRS+DIRS}
${SRC+SRC} ${LIBSRC+LIBSRC} ${LIBOBJ+LIBOBJ} ${ALL+ALL}
${EXHEADER+EXHEADER} ${HEADER+HEADER}${GENERAL+GENERAL}
${CFLAGS+CFLAGS} ${ASFLAGS+ASFLAGS} ${AFLAGS+AFLAGS}
${LDCMD+LDCMD} ${LDFLAGS+LDFLAGS}${SHAREDCMD+SHAREDCMD}
${SHAREDFLAGS+SHAREDFLAGS} ${SHARED_LIB+SHARED_LIB}
${LIBEXTRAS+LIBEXTRAS} make -e PLATFORM='aix64-cc' PROCESSOR=''
CC='cc' CFLAG='-DOPENSSL_THREADS -qthreaded -DDSO_DLFCN -DHAVE_DLFCN_H
-q64 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst'
AS='cc' ASFLAG='-DOPENSSL_THREADS -qthreaded -DDSO_DLFCN -DHAVE_DLFCN_H
-q64 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -c'
AR='ar -X 64 r' PERL='/usr/bin/perl' RANLIB='/usr/bin/ranlib'
SDIRS='objects md2 md4 md5 sha hmac ripemd des aes rc2 rc4 idea bf
cast bn ec rsa dsa ecdsa dh ecdh dso engine buffer bio stack lhash
rand err evp asn1 pem x509 x509v3 conf txt_db pkcs7 pkcs12 comp ocsp ui
krb5 store pqueue' LIBRPATH='/usr/local/ssl/lib'
INSTALL_PREFIX=''INSTALLTOP='/usr/local/ssl'
OPENSSLDIR='/usr/local/ssl' MAKEDEPEND='$${TOP}/util/domd $${TOP}
-MD makedepend' DEPFLAG='-DOPENSSL_NO_DEPRECATED
[openssl.org #1850] Bug Report--openssl crashes at SSL_write()
Hello, we found openssl crashing at the function SSL_write() after some repeated calls. The debug of the core follows: Program terminated with signal 11, Segmentation fault. SEGV_ACCERR - Invalid Permissions for object warning: No unwind information found. Skipping this library /local/twsmdm/bin/libicudata.sl.34. #0 0xc000125ed640:0 in SSL_write () at ssl_lib.c:866 866 ssl_lib.c: No such file or directory. in ssl_lib.c Please find the backtrace of the core below (gdb) bt #0 0xc000125ed640:0 in SSL_write () at ssl_lib.c:866 #1 0xc000125c5620:0 in HTTPSSLChannel::WriteToSocket ( this=0x600e0880, psTxBuffer=0x800315a0 C_100323\!-- Follow dependecies --/predecessor\n/dependencies\n/job\n\n\t\t\tjob name=\L21FTPMUBR_KBC_150987\ definition=\jd=P97209023#L21FTPMUBR_KBC_150987\ confirmed=\False\ isKey=\False\ priori..., iSize=3911) at ../../../../../../src/weblib/wscc/transport/axis3/HTTPSSLChannel/HTTPSSLChannel.cpp:773 #2 0xc000125bf2a0:0 in HTTPSSLChannel::operator ( this=0x600e0880, msg=0x800315a0 C_100323\!-- Follow dependecies --/predecessor\n/dependencies\n/job\n\n\t\t\tjob name=\L21FTPMUBR_KBC_150987\ definition=\jd=P97209023#L21FTPMUBR_KBC_150987\ confirmed=\False\ isKey=\False\ priori...) at ../../../../../../src/weblib/wscc/transport/axis3/HTTPSSLChannel/HTTPSSLChannel.cpp:274 #3 0xc5462ec0:0 in HTTPTransport::flushOutput ( this=0x60100d10) at ../../../../../src/weblib/wscc/transport/axis3/HTTPTransport.cpp:336 #4 0x4032ae20:0 in WebHTTPDialog (pTransp=0x60100d10, hndlrs=0x80039e60, lastShot=0) at ../../src/weblib/web_client.cxx:883 ---Type return to continue, or q return to quit--- #5 0x403299a0:0 in WebPostRequestUseOnlyParms ( servletPath=0x60011280 CLIModelWeb/ModelServlet, parms=0x80039df8, hndlrs=0x80039e60) at ../../src/weblib/web_client.cxx:716 #6 0x401b5ab0:0 in xml_exec_post (parameter=0x80039df0, hndlrs=0x80039e60) at ../../src/composer_new/xmlsend.c:509 #7 0x401b4e00:0 in xml_send_object (cspc=0x6007b790, idtype=id_sched) at ../../src/composer_new/xmlsend.c:417 #8 0x401cd8a0:0 in xml_end_Jobstream (sspc=0x6007b790) at ../../src/composer_new/xmljobstream.c:618 #9 0x4015fe10:0 in sch_yyparse () at ../../src/parse/sparser.y:495 #10 0x40182560:0 in sch_parser ( filename=0x8003d220 /local/twsmdm/tmp/TWSAAAa12476, orig_filename=0x8003ae20 sch82b, sym_ver=1, df=1) at ../../src/parse/sparser.y:3411 #11 0x40147f20:0 in com_interpret_file (pc=0x6007b790, filename=0x8003d220 /local/twsmdm/tmp/TWSAAAa12476, orig_filename=0x8003ae20 sch82b) at ../../src/composer_new/comutils.c:182 #12 0x40134750:0 in com_do_command (command_data=0x8003f200, user_data=0x6007b790) at ../../src/composer_new/comparse.c:2281 #13 0x403f43c0:0 in parse_command ( line=0x600e1bc0 rep sch82b, line_length=10, ---Type return to continue, or q return to quit--- parse_control=0x6009b430, error_value=0x8003f280, error_position=0x8003f282) at ../../src/libs/tokenize.c:1951 #14 0x40146960:0 in com_process_commands (com=0x6007b790) at ../../src/composer_new/composer.c:124 #15 0x40147ad0:0 in main (argc=1, argv=0x8003f7d8) at ../../src/composer_new/composer.c:270 OS : HP-UX B.11.23 U ia64 openssl version : openssl 0.9.7j compiled with the native compiler. Thanks Regards, BhanuPrakash.T __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Support DTLS compatibility with Cisco AnyConnect VPN [openssl.org #1751]
On Wed, Feb 25, 2009 at 1:44 PM, David Woodhouse dw...@infradead.org wrote: Hello? Is there anybody out there? I hear you. Not that that helps much; maybe you need to address the core team directly. Don't know why this is happening like this, maybe your patch is counter-policy or some such, but for lack of sound, the why remains pure guesswork. Anyway, thanks for posting it here as I may be needing it in a while - another case of interoperability gaining over proper standards-conforming protocol usage coming my way. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1751] [PATCH] Support DTLS compatibility with Cisco AnyConnect VPN
On Wed, 2009-02-25 at 16:38 +0100, Ben Laurie via RT wrote:
[dw...@infradead.org - Sat Dec 20 14:00:34 2008]:
On Tue, 2008-10-07 at 10:12 +0100, David Woodhouse wrote:
This patch against the 0.9.8 branch adds an SSL option for compatibility
with the pre-RFC version of DTLS used by Cisco for their AnyConnect SSL
VPN. This is RT #1751.
With this patch, and with the two bug fixes I just posted, I now have a
fully functional client operating with Cisco's VPN servers.
Leaving aside the question of adding this to HEAD, can we please at
least add it to the 0.9.8 branch?
Adding to HEAD seems less problematic.
Well, the stable branch already has back-compat support for a new server
to talk to old clients. So it's kind of a no-brainer to make it work the
other way round too; new client code talking to old servers.
HEAD doesn't have that back-compat at all; a patch would be larger
there. I can certainly generate such a patch though. As soon as I'm not
in a hotel which blocks UDP traffic... :)
Anyway, I'm mostly happy with this patch, except from d1_pkt.c, shouldn't:
if (s-client_version == DTLS1_BAD_VER || s-version == DTLS1_BAD_VER)
ccs_hdr_len = 3;
be
if (s-client_version == DTLS1_BAD_VER || (s-options
SSL_OP_CISCO_ANYCONNECT))
ccs_hdr_len = 3;
Those are equivalent, I believe -- you should never hit this code path
with s-version == DTLS1_BAD_VER unless the ANYCONNECT option is set.
So it's purely a cosmetic thing -- I can change it if you prefer.
also, the patch as an attachment would be nice.
I'm attaching the 0.9.8x patch I've been building with for the last few
months. Generating a patch against HEAD will take me a little longer
(and be less directly useful, in the foreseeable future, because
distributions are actually shipping 0.9.8x.)
--
dwmw2
Index: ssl/d1_clnt.c
===
RCS file: /home/dwmw2/openssl-cvs/openssl/ssl/d1_clnt.c,v
retrieving revision 1.3.2.10
diff -u -p -r1.3.2.10 d1_clnt.c
--- ssl/d1_clnt.c 4 Jun 2008 18:35:25 - 1.3.2.10
+++ ssl/d1_clnt.c 29 Sep 2008 08:27:31 -
@@ -130,7 +130,7 @@ static int dtls1_get_hello_verify(SSL *s
static SSL_METHOD *dtls1_get_client_method(int ver)
{
- if (ver == DTLS1_VERSION)
+ if (ver == DTLS1_VERSION || ver == DTLS1_BAD_VER)
return(DTLSv1_client_method());
else
return(NULL);
@@ -181,7 +181,8 @@ int dtls1_connect(SSL *s)
s-server=0;
if (cb != NULL) cb(s,SSL_CB_HANDSHAKE_START,1);
- if ((s-version 0xff00 ) != (DTLS1_VERSION 0xff00))
+ if ((s-version 0xff00 ) != (DTLS1_VERSION 0xff00)
+ (s-version 0xff00 ) != (DTLS1_BAD_VER 0xff00))
{
SSLerr(SSL_F_DTLS1_CONNECT, ERR_R_INTERNAL_ERROR);
ret = -1;
Index: ssl/d1_lib.c
===
RCS file: /home/dwmw2/openssl-cvs/openssl/ssl/d1_lib.c,v
retrieving revision 1.1.2.5
diff -u -p -r1.1.2.5 d1_lib.c
--- ssl/d1_lib.c 5 Oct 2007 21:05:27 - 1.1.2.5
+++ ssl/d1_lib.c 29 Sep 2008 08:38:49 -
@@ -186,7 +186,10 @@ void dtls1_free(SSL *s)
void dtls1_clear(SSL *s)
{
ssl3_clear(s);
- s-version=DTLS1_VERSION;
+ if (s-options SSL_OP_CISCO_ANYCONNECT)
+ s-version=DTLS1_BAD_VER;
+ else
+ s-version=DTLS1_VERSION;
}
/*
Index: ssl/d1_pkt.c
===
RCS file: /home/dwmw2/openssl-cvs/openssl/ssl/d1_pkt.c,v
retrieving revision 1.4.2.12
diff -u -p -r1.4.2.12 d1_pkt.c
--- ssl/d1_pkt.c 14 Sep 2008 17:57:03 - 1.4.2.12
+++ ssl/d1_pkt.c 29 Sep 2008 08:27:31 -
@@ -986,15 +986,17 @@ start:
if (rr-type == SSL3_RT_CHANGE_CIPHER_SPEC)
{
struct ccs_header_st ccs_hdr;
+ int ccs_hdr_len = DTLS1_CCS_HEADER_LENGTH;
dtls1_get_ccs_header(rr-data, ccs_hdr);
/* 'Change Cipher Spec' is just a single byte, so we know
* exactly what the record payload has to look like */
/* XDTLS: check that epoch is consistent */
- if ( (s-client_version == DTLS1_BAD_VER rr-length != 3) ||
- (s-client_version != DTLS1_BAD_VER rr-length != DTLS1_CCS_HEADER_LENGTH) ||
- (rr-off != 0) || (rr-data[0] != SSL3_MT_CCS))
+ if (s-client_version == DTLS1_BAD_VER || s-version == DTLS1_BAD_VER)
+ ccs_hdr_len = 3;
+
+ if ((rr-length != ccs_hdr_len) || (rr-off != 0) || (rr-data[0] != SSL3_MT_CCS))
{
i=SSL_AD_ILLEGAL_PARAMETER;
SSLerr(SSL_F_DTLS1_READ_BYTES,SSL_R_BAD_CHANGE_CIPHER_SPEC);
@@ -1310,7 +1312,7 @@ int do_dtls1_write(SSL *s, int type, con
#if 0
/* 'create_empty_fragment' is true only when this function calls itself */
if (!clear !create_empty_fragment !s-s3-empty_fragment_done
- SSL_version(s) != DTLS1_VERSION)
+ SSL_version(s) != DTLS1_VERSION SSL_version(s) != DTLS1_BAD_VER)
{
/* countermeasure against known-IV weakness in CBC ciphersuites
* (see http://www.openssl.org/~bodo/tls-cbc.txt)
Index: ssl/s3_clnt.c
===
RCS file:
Re: [openssl.org #1751] [PATCH] Support DTLS compatibility with Cisco AnyConnect VPN
On Wed, 2009-02-25 at 16:38 +0100, Ben Laurie via RT wrote:
[dw...@infradead.org - Sat Dec 20 14:00:34 2008]:
On Tue, 2008-10-07 at 10:12 +0100, David Woodhouse wrote:
This patch against the 0.9.8 branch adds an SSL option for compatibility
with the pre-RFC version of DTLS used by Cisco for their AnyConnect SSL
VPN. This is RT #1751.
With this patch, and with the two bug fixes I just posted, I now have a
fully functional client operating with Cisco's VPN servers.
Leaving aside the question of adding this to HEAD, can we please at
least add it to the 0.9.8 branch?
Adding to HEAD seems less problematic.
Well, the stable branch already has back-compat support for a new server
to talk to old clients. So it's kind of a no-brainer to make it work the
other way round too; new client code talking to old servers.
HEAD doesn't have that back-compat at all; a patch would be larger
there. I can certainly generate such a patch though. As soon as I'm not
in a hotel which blocks UDP traffic... :)
Anyway, I'm mostly happy with this patch, except from d1_pkt.c, shouldn't:
if (s-client_version == DTLS1_BAD_VER || s-version == DTLS1_BAD_VER)
ccs_hdr_len = 3;
be
if (s-client_version == DTLS1_BAD_VER || (s-options
SSL_OP_CISCO_ANYCONNECT))
ccs_hdr_len = 3;
Those are equivalent, I believe -- you should never hit this code path
with s-version == DTLS1_BAD_VER unless the ANYCONNECT option is set.
So it's purely a cosmetic thing -- I can change it if you prefer.
also, the patch as an attachment would be nice.
I'm attaching the 0.9.8x patch I've been building with for the last few
months. Generating a patch against HEAD will take me a little longer
(and be less directly useful, in the foreseeable future, because
distributions are actually shipping 0.9.8x.)
--
dwmw2
Index: ssl/d1_clnt.c
===
RCS file: /home/dwmw2/openssl-cvs/openssl/ssl/d1_clnt.c,v
retrieving revision 1.3.2.10
diff -u -p -r1.3.2.10 d1_clnt.c
--- ssl/d1_clnt.c 4 Jun 2008 18:35:25 - 1.3.2.10
+++ ssl/d1_clnt.c 29 Sep 2008 08:27:31 -
@@ -130,7 +130,7 @@ static int dtls1_get_hello_verify(SSL *s
static SSL_METHOD *dtls1_get_client_method(int ver)
{
- if (ver == DTLS1_VERSION)
+ if (ver == DTLS1_VERSION || ver == DTLS1_BAD_VER)
return(DTLSv1_client_method());
else
return(NULL);
@@ -181,7 +181,8 @@ int dtls1_connect(SSL *s)
s-server=0;
if (cb != NULL) cb(s,SSL_CB_HANDSHAKE_START,1);
- if ((s-version 0xff00 ) != (DTLS1_VERSION 0xff00))
+ if ((s-version 0xff00 ) != (DTLS1_VERSION 0xff00)
+ (s-version 0xff00 ) != (DTLS1_BAD_VER 0xff00))
{
SSLerr(SSL_F_DTLS1_CONNECT, ERR_R_INTERNAL_ERROR);
ret = -1;
Index: ssl/d1_lib.c
===
RCS file: /home/dwmw2/openssl-cvs/openssl/ssl/d1_lib.c,v
retrieving revision 1.1.2.5
diff -u -p -r1.1.2.5 d1_lib.c
--- ssl/d1_lib.c 5 Oct 2007 21:05:27 - 1.1.2.5
+++ ssl/d1_lib.c 29 Sep 2008 08:38:49 -
@@ -186,7 +186,10 @@ void dtls1_free(SSL *s)
void dtls1_clear(SSL *s)
{
ssl3_clear(s);
- s-version=DTLS1_VERSION;
+ if (s-options SSL_OP_CISCO_ANYCONNECT)
+ s-version=DTLS1_BAD_VER;
+ else
+ s-version=DTLS1_VERSION;
}
/*
Index: ssl/d1_pkt.c
===
RCS file: /home/dwmw2/openssl-cvs/openssl/ssl/d1_pkt.c,v
retrieving revision 1.4.2.12
diff -u -p -r1.4.2.12 d1_pkt.c
--- ssl/d1_pkt.c 14 Sep 2008 17:57:03 - 1.4.2.12
+++ ssl/d1_pkt.c 29 Sep 2008 08:27:31 -
@@ -986,15 +986,17 @@ start:
if (rr-type == SSL3_RT_CHANGE_CIPHER_SPEC)
{
struct ccs_header_st ccs_hdr;
+ int ccs_hdr_len = DTLS1_CCS_HEADER_LENGTH;
dtls1_get_ccs_header(rr-data, ccs_hdr);
/* 'Change Cipher Spec' is just a single byte, so we know
* exactly what the record payload has to look like */
/* XDTLS: check that epoch is consistent */
- if ( (s-client_version == DTLS1_BAD_VER rr-length != 3) ||
- (s-client_version != DTLS1_BAD_VER rr-length != DTLS1_CCS_HEADER_LENGTH) ||
- (rr-off != 0) || (rr-data[0] != SSL3_MT_CCS))
+ if (s-client_version == DTLS1_BAD_VER || s-version == DTLS1_BAD_VER)
+ ccs_hdr_len = 3;
+
+ if ((rr-length != ccs_hdr_len) || (rr-off != 0) || (rr-data[0] != SSL3_MT_CCS))
{
i=SSL_AD_ILLEGAL_PARAMETER;
SSLerr(SSL_F_DTLS1_READ_BYTES,SSL_R_BAD_CHANGE_CIPHER_SPEC);
@@ -1310,7 +1312,7 @@ int do_dtls1_write(SSL *s, int type, con
#if 0
/* 'create_empty_fragment' is true only when this function calls itself */
if (!clear !create_empty_fragment !s-s3-empty_fragment_done
- SSL_version(s) != DTLS1_VERSION)
+ SSL_version(s) != DTLS1_VERSION SSL_version(s) != DTLS1_BAD_VER)
{
/* countermeasure against known-IV weakness in CBC ciphersuites
* (see http://www.openssl.org/~bodo/tls-cbc.txt)
Index: ssl/s3_clnt.c
===
RCS file:
