Re: [Chicken-users] OpenSSL egg option defaults poll
On 27/11/14 03:00, Florian Zumbiehl wrote: > Hi, > >> ... and now version (4) with the dynamic-wind in the correct place: > > I think the logic is correct now, just two small cosmectic issues: > >> diff -upr v1.6.4/openssl.import.scm v1.6.4-andyjpb-fix-4/openssl.import.scm >> --- v1.6.4/openssl.import.scm2014-11-23 02:37:31.235897645 + >> +++ v1.6.4-andyjpb-fix-4/openssl.import.scm 2014-11-23 02:13:16.085352751 + >> @@ -1,6 +1,6 @@ >> openssl.import.scm - GENERATED BY CHICKEN 4.9.0rc1 -*- Scheme -*- >> >> -(eval '(import scheme chicken foreign ports srfi-18 tcp)) >> +(eval '(import scheme chicken foreign ports srfi-13 srfi-18 tcp)) >> (##sys#register-compiled-module >>'openssl >>(list) > > That probably shouldn't be in the diff? Ooops. Yes. I think I removed it from some and not others. >> + (unbuffered-write >> + (lambda (buffer #!optional (offset 0) (size (##sys#size buffer))) > > unbuffered-write doesn't ever get called with an offset other than 0. True, but I wanted to keep the interface reasonably conventional. I didn't rework the internals of unbuffered-write due to the when clause but if we did then it would be used. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, > ... and now version (4) with the dynamic-wind in the correct place: I think the logic is correct now, just two small cosmectic issues: > diff -upr v1.6.4/openssl.import.scm v1.6.4-andyjpb-fix-4/openssl.import.scm > --- v1.6.4/openssl.import.scm 2014-11-23 02:37:31.235897645 + > +++ v1.6.4-andyjpb-fix-4/openssl.import.scm 2014-11-23 02:13:16.085352751 > + > @@ -1,6 +1,6 @@ > openssl.import.scm - GENERATED BY CHICKEN 4.9.0rc1 -*- Scheme -*- > > -(eval '(import scheme chicken foreign ports srfi-18 tcp)) > +(eval '(import scheme chicken foreign ports srfi-13 srfi-18 tcp)) > (##sys#register-compiled-module >'openssl >(list) That probably shouldn't be in the diff? :-) > + (unbuffered-write > + (lambda (buffer #!optional (offset 0) (size (##sys#size > buffer))) unbuffered-write doesn't ever get called with an offset other than 0. Florian ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, ... and now version (4) with the dynamic-wind in the correct place: - $ diff -upr v1.6.4-andyjpb-fix-3 v1.6.4-andyjpb-fix-4 Binary files v1.6.4-andyjpb-fix-3/openssl.import.so and v1.6.4-andyjpb-fix-4/openssl.import.so differ diff -upr v1.6.4-andyjpb-fix-3/openssl.scm v1.6.4-andyjpb-fix-4/openssl.scm --- v1.6.4-andyjpb-fix-3/openssl.scm2014-11-25 15:53:35.035152667 + +++ v1.6.4-andyjpb-fix-4/openssl.scm2014-11-25 16:21:59.105377994 + @@ -481,17 +481,16 @@ EOF (unbuffered-write buffer))) ;; close (lambda () - (dynamic-wind -void -(lambda () - (when (startup #t) -(if outbuf - (begin -(unbuffered-write outbuf 0 outbufsize) -(set! outbufsize 0) -(lambda () - (set! out-open? #f) - (shutdown + (when (startup #t) +(dynamic-wind + void + (lambda () +(when outbuf + (unbuffered-write outbuf 0 outbufsize) + (set! outbufsize 0))) + (lambda () +(set! out-open? #f) +(shutdown) ;; flush (lambda () (when outbuf - Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF diff -upr v1.6.4/openssl.import.scm v1.6.4-andyjpb-fix-4/openssl.import.scm --- v1.6.4/openssl.import.scm 2014-11-23 02:37:31.235897645 + +++ v1.6.4-andyjpb-fix-4/openssl.import.scm 2014-11-23 02:13:16.085352751 + @@ -1,6 +1,6 @@ openssl.import.scm - GENERATED BY CHICKEN 4.9.0rc1 -*- Scheme -*- -(eval '(import scheme chicken foreign ports srfi-18 tcp)) +(eval '(import scheme chicken foreign ports srfi-13 srfi-18 tcp)) (##sys#register-compiled-module 'openssl (list) Binary files v1.6.4/openssl.import.so and v1.6.4-andyjpb-fix-4/openssl.import.so differ diff -upr v1.6.4/openssl.scm v1.6.4-andyjpb-fix-4/openssl.scm --- v1.6.4/openssl.scm 2014-11-23 00:07:52.324097414 + +++ v1.6.4-andyjpb-fix-4/openssl.scm 2014-11-25 16:21:59.105377994 + @@ -45,7 +45,7 @@ ##sys#check-string ##sys#expand-home-path)) -(use srfi-18 tcp) +(use srfi-13 srfi-18 tcp) #> #include @@ -442,43 +442,61 @@ EOF "SSL read timed out"))) buffer (out - (let* ((outbufsize (tcp-buffer-size)) - (outbuf (and outbufsize (fx> outbufsize 0) "")) - (output - (lambda (buffer) - (startup) - (when (> (##sys#size buffer) 0) ; Undefined behaviour for 0 bytes! - (let loop ((offset 0) (size (##sys#size buffer))) + (let* ((outbufmax (tcp-buffer-size)) + (outbuf (and outbufmax (fx> outbufmax 0) (make-string outbufmax))) + (outbufsize 0) + (unbuffered-write + (lambda (buffer #!optional (offset 0) (size (##sys#size buffer))) + (when (> size 0) ; Undefined behaviour for 0 bytes! + (let loop ((offset offset) (size size)) (let ((ret (ssl-call/timeout 'ssl-write (lambda () (ssl-write ssl buffer offset size)) fd (tcp-write-timeout) "SSL write timed out"))) (when (fx< ret size) ; Partial write (loop (fx+ offset ret) (fx- size ret) + + (define (buffered-write data #!optional (start 0)) + (let* ((size (- (##sys#size data) start)) + (to-copy (min (- outbufmax outbufsize) size)) + (left-over (- size to-copy))) + + (string-copy! outbuf outbufsize data start (+ start to-copy)) + (set! outbufsize (+ outbufsize to-copy)) + + (if (= outbufsize outbufmax) + (begin + (unbuffered-write outbuf) + (set! outbufsize 0))) + + (if (> left-over 0) + (buffered-write data (+ start to-copy) + (make-output-port ;; write (lambda (buffer) + (startup) (if outbuf - (begin - (set! outbuf (string-append outbuf buffer)) - (when (fx>= (string-length outbuf) outbufsize) - (output outbuf) - (set! outbuf ""))) - (output buffer))) + (buffered-write buffer) + (unbuffered-write buffer))) ;; close (lambda () (when (startup #t) - (if outbuf - (begin - (output outbuf) - (set! outbuf ""))) - (set! out-open? #f) - (shutdown))) + (dynamic-wind + void + (lambda () + (when outbuf + (unbuffered-write outbuf 0 outbufsize) + (set! outbufsize 0))) + (lambda () + (set! out-open? #f) + (shutdown) ;; flush (lambda () (when outbuf - (output outbuf) - (set! outbuf ""))) + (startup) + (unbuffered-write outbuf 0 outbufsize) + (set! outbufsize 0))) (##sys#setslot in 3 "(ssl)") (##sys#setslot out 3 "(ssl)") ;; first "reserved" slot Only in v1.6.4-andyjpb-fix-4: openssl.scm~ Only in v1.6.4-andyjpb-fix-4: .openssl.scm.swp Binary files v1.6.4/openssl.so and v1.6.4-andyjpb-fix-4/openssl.so
Re: [Chicken-users] OpenSSL egg option defaults poll
On 23/11/14 18:38, Florian Zumbiehl wrote: > Hi, > >> ;; close >> (lambda () >> (when (startup #t) >> (if outbuf >> - (begin >> - (output outbuf) >> - (set! outbuf ""))) >> + (begin >> + (unbuffered-write outbuf 0 outbufsize) >> + (set! outbufsize 0))) >> (set! out-open? #f) >> (shutdown))) > > AFAICS, this makes it impossible to close the file descriptors behind ports > where the remote end has closed the connection while there is still data > queued for transmission. Find a new version of the patch attached. This is version (3) and is against v1.6.4. A diff against versiion (2) is here: - diff -upr v1.6.4-andyjpb-fix-2/openssl.scm v1.6.4-andyjpb-fix-3/openssl.scm --- v1.6.4-andyjpb-fix-2/openssl.scm2014-11-23 13:10:43.801483458 + +++ v1.6.4-andyjpb-fix-3/openssl.scm2014-11-25 15:53:35.035152667 + @@ -481,13 +481,17 @@ EOF (unbuffered-write buffer))) ;; close (lambda () - (when (startup #t) -(if outbuf - (begin -(unbuffered-write outbuf 0 outbufsize) -(set! outbufsize 0))) -(set! out-open? #f) -(shutdown))) + (dynamic-wind +void +(lambda () + (when (startup #t) +(if outbuf + (begin +(unbuffered-write outbuf 0 outbufsize) +(set! outbufsize 0) +(lambda () + (set! out-open? #f) + (shutdown ;; flush (lambda () (when outbuf - Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF diff -upr v1.6.4/openssl.scm v1.6.4-andyjpb-fix-3/openssl.scm --- v1.6.4/openssl.scm 2014-11-23 00:07:52.324097414 + +++ v1.6.4-andyjpb-fix-3/openssl.scm 2014-11-25 15:53:35.035152667 + @@ -45,7 +45,7 @@ ##sys#check-string ##sys#expand-home-path)) -(use srfi-18 tcp) +(use srfi-13 srfi-18 tcp) #> #include @@ -442,43 +442,62 @@ EOF "SSL read timed out"))) buffer (out - (let* ((outbufsize (tcp-buffer-size)) - (outbuf (and outbufsize (fx> outbufsize 0) "")) - (output - (lambda (buffer) - (startup) - (when (> (##sys#size buffer) 0) ; Undefined behaviour for 0 bytes! - (let loop ((offset 0) (size (##sys#size buffer))) + (let* ((outbufmax (tcp-buffer-size)) + (outbuf (and outbufmax (fx> outbufmax 0) (make-string outbufmax))) + (outbufsize 0) + (unbuffered-write + (lambda (buffer #!optional (offset 0) (size (##sys#size buffer))) + (when (> size 0) ; Undefined behaviour for 0 bytes! + (let loop ((offset offset) (size size)) (let ((ret (ssl-call/timeout 'ssl-write (lambda () (ssl-write ssl buffer offset size)) fd (tcp-write-timeout) "SSL write timed out"))) (when (fx< ret size) ; Partial write (loop (fx+ offset ret) (fx- size ret) + + (define (buffered-write data #!optional (start 0)) + (let* ((size (- (##sys#size data) start)) + (to-copy (min (- outbufmax outbufsize) size)) + (left-over (- size to-copy))) + + (string-copy! outbuf outbufsize data start (+ start to-copy)) + (set! outbufsize (+ outbufsize to-copy)) + + (if (= outbufsize outbufmax) + (begin + (unbuffered-write outbuf) + (set! outbufsize 0))) + + (if (> left-over 0) + (buffered-write data (+ start to-copy) + (make-output-port ;; write (lambda (buffer) + (startup) (if outbuf - (begin - (set! outbuf (string-append outbuf buffer)) - (when (fx>= (string-length outbuf) outbufsize) - (output outbuf) - (set! outbuf ""))) - (output buffer))) + (buffered-write buffer) + (unbuffered-write buffer))) ;; close (lambda () - (when (startup #t) - (if outbuf - (begin - (output outbuf) - (set! outbuf ""))) - (set! out-open? #f) - (shutdown))) + (dynamic-wind + void + (lambda () + (when (startup #t) + (if outbuf + (begin + (unbuffered-write outbuf 0 outbufsize) + (set! outbufsize 0) + (lambda () + (set! out-open? #f) + (shutdown ;; flush (lambda () (when outbuf - (output outbuf) - (set! outbuf ""))) + (startup) + (unbuffered-write outbuf 0 outbufsize) + (set! outbufsize 0))) (##sys#setslot in 3 "(ssl)") (##sys#setslot out 3 "(ssl)") ;; first "reserved" slot ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, >;; close >(lambda () > (when (startup #t) >(if outbuf > - (begin > -(output outbuf) > -(set! outbuf ""))) > +(begin > + (unbuffered-write outbuf 0 outbufsize) > + (set! outbufsize 0))) >(set! out-open? #f) >(shutdown))) AFAICS, this makes it impossible to close the file descriptors behind ports where the remote end has closed the connection while there is still data queued for transmission. Florian ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, >>> I'd be glad if some of you could test this out and tell me what you >>> think about it >> >> Can you give some tips for how to test this from a spiffy applications? >> I usually just pass in ssl-accept instead of tcp-accept. >> [...] > > Hello, > > actually I have very little experience with spiffy, but if it can use > ssl-accept, it must use ssl-listen somewhere and that's the point that > would need to be adapted. > > Judging by Spiffy's documentation in the Wiki you could do something > like this: > > (define ear > (ssl-listen* > hostname: "localhost" port: 44344 > certificate: "my-server-cert.pem" > private-key: "my-server-key.pem")) > (accept-loop ear ssl-accept) > > Beware, this snippet of code is completely untested! I've just tried this. I have openssl 1.0.1e-2+deb7u13 on my localhost With ssl-listen: $ nmap --script ssl-enum-ciphers -sV -p 8080 127.0.0.1 - | ssl-enum-ciphers: | SSLv3 | Ciphers (9) | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - unknown strength | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - unknown strength | TLS_RSA_WITH_DES_CBC_SHA - unknown strength | TLS_RSA_WITH_RC4_128_MD5 - unknown strength | TLS_RSA_WITH_RC4_128_SHA - strong | TLS_RSA_WITH_SEED_CBC_SHA - unknown strength | Compressors (1) | NULL | TLSv1.0 | Ciphers (9) | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - unknown strength | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - unknown strength | TLS_RSA_WITH_DES_CBC_SHA - unknown strength | TLS_RSA_WITH_RC4_128_MD5 - unknown strength | TLS_RSA_WITH_RC4_128_SHA - strong | TLS_RSA_WITH_SEED_CBC_SHA - unknown strength | Compressors (1) | NULL | TLSv1.1 | Ciphers (9) | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - unknown strength | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - unknown strength | TLS_RSA_WITH_DES_CBC_SHA - unknown strength | TLS_RSA_WITH_RC4_128_MD5 - unknown strength | TLS_RSA_WITH_RC4_128_SHA - strong | TLS_RSA_WITH_SEED_CBC_SHA - unknown strength | Compressors (1) | NULL | TLSv1.2 | Ciphers (13) | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength | TLS_RSA_WITH_AES_256_CBC_SHA256 - unknown strength | TLS_RSA_WITH_AES_256_GCM_SHA384 - unknown strength | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - unknown strength | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - unknown strength | TLS_RSA_WITH_DES_CBC_SHA - unknown strength | TLS_RSA_WITH_RC4_128_MD5 - unknown strength | TLS_RSA_WITH_RC4_128_SHA - strong | TLS_RSA_WITH_SEED_CBC_SHA - unknown strength | Compressors (1) | NULL |_ Least strength = unknown strength - With ssl-listen*: - | ssl-enum-ciphers: | TLSv1.2 | Ciphers (13) | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength | TLS_RSA_WITH_AES_256_CBC_SHA256 - unknown strength | TLS_RSA_WITH_AES_256_GCM_SHA384 - unknown strength | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - unknown strength | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - unknown strength | TLS_RSA_WITH_DES_CBC_SHA - unknown strength | TLS_RSA_WITH_RC4_128_MD5 - unknown strength | TLS_RSA_WITH_RC4_128_SHA - strong | TLS_RSA_WITH_SEED_CBC_SHA - unknown strength | Compressors (1) | NULL |_ Least strength = unknown strength - I'm not sure I entirely trust nmap as other the openssl tool shows that zlib compression is negotiated when using either ssl-listen or ssl-listen* ssl-listen: - New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1.2 Cipher: AES256-GCM-SHA384 Session-ID: ADB914DDE44B74FABB090BFAA419BCE65B3969B5C1CA1981007B43E4DFEE21BE Session-ID-ctx: Master-Key: F148213C9B6AA23159CFD29129833A3DBB283B611B6234636B3F5F355FB5BA06C9BB740B4408ADF2B404817BCE24F27C Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: - 48 89 c5 a
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, >> * substring/shared is the same as substring in CHICKEN, AFAIK. > > That's only called once in the corner cases so it doesn't really matter > if it wastes a copy. It's just there to stop junk in the tail of the > buffer being sent to the user. Attached is new version of my patch which avoids the use of substring/shared. Below is a diff between the code with my previous patch and the code with this new patch. - diff -upr v1.6.4-andyjpb-fix/openssl.scm v1.6.4-andyjpb-fix-2/openssl.scm --- v1.6.4-andyjpb-fix/openssl.scm 2014-11-23 02:31:54.004264327 + +++ v1.6.4-andyjpb-fix-2/openssl.scm2014-11-23 13:10:43.801483458 + @@ -446,9 +446,9 @@ EOF (outbuf (and outbufmax (fx> outbufmax 0) (make-string outbufmax))) (outbufsize 0) (unbuffered-write - (lambda (buffer) - (when (> (##sys#size buffer) 0) ; Undefined behaviour for 0 bytes! - (let loop ((offset 0) (size (##sys#size buffer))) + (lambda (buffer #!optional (offset 0) (size (##sys#size buffer))) + (when (> size 0) ; Undefined behaviour for 0 bytes! + (let loop ((offset offset) (size size)) (let ((ret (ssl-call/timeout 'ssl-write (lambda () (ssl-write ssl buffer offset size)) @@ -484,7 +484,7 @@ EOF (when (startup #t) (if outbuf (begin -(unbuffered-write (substring/shared outbuf 0 outbufsize)) +(unbuffered-write outbuf 0 outbufsize) (set! outbufsize 0))) (set! out-open? #f) (shutdown))) @@ -492,7 +492,7 @@ EOF (lambda () (when outbuf (startup) -(unbuffered-write (substring/shared outbuf 0 outbufsize)) +(unbuffered-write outbuf 0 outbufsize) (set! outbufsize 0))) (##sys#setslot in 3 "(ssl)") (##sys#setslot out 3 "(ssl)") - Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF diff -upr v1.6.4/openssl.scm v1.6.4-andyjpb-fix-2/openssl.scm --- v1.6.4/openssl.scm 2014-11-23 00:07:52.324097414 + +++ v1.6.4-andyjpb-fix-2/openssl.scm 2014-11-23 13:10:43.801483458 + @@ -45,7 +45,7 @@ ##sys#check-string ##sys#expand-home-path)) -(use srfi-18 tcp) +(use srfi-13 srfi-18 tcp) #> #include @@ -442,43 +442,58 @@ EOF "SSL read timed out"))) buffer (out - (let* ((outbufsize (tcp-buffer-size)) - (outbuf (and outbufsize (fx> outbufsize 0) "")) - (output - (lambda (buffer) - (startup) - (when (> (##sys#size buffer) 0) ; Undefined behaviour for 0 bytes! - (let loop ((offset 0) (size (##sys#size buffer))) + (let* ((outbufmax (tcp-buffer-size)) + (outbuf (and outbufmax (fx> outbufmax 0) (make-string outbufmax))) + (outbufsize 0) + (unbuffered-write + (lambda (buffer #!optional (offset 0) (size (##sys#size buffer))) + (when (> size 0) ; Undefined behaviour for 0 bytes! + (let loop ((offset offset) (size size)) (let ((ret (ssl-call/timeout 'ssl-write (lambda () (ssl-write ssl buffer offset size)) fd (tcp-write-timeout) "SSL write timed out"))) (when (fx< ret size) ; Partial write (loop (fx+ offset ret) (fx- size ret) + + (define (buffered-write data #!optional (start 0)) + (let* ((size (- (##sys#size data) start)) + (to-copy (min (- outbufmax outbufsize) size)) + (left-over (- size to-copy))) + + (string-copy! outbuf outbufsize data start (+ start to-copy)) + (set! outbufsize (+ outbufsize to-copy)) + + (if (= outbufsize outbufmax) + (begin + (unbuffered-write outbuf) + (set! outbufsize 0))) + + (if (> left-over 0) + (buffered-write data (+ start to-copy) + (make-output-port ;; write (lambda (buffer) + (startup) (if outbuf - (begin - (set! outbuf (string-append outbuf buffer)) - (when (fx>= (string-length outbuf) outbufsize) - (output outbuf) - (set! outbuf ""))) - (output buffer))) + (buffered-write buffer) + (unbuffered-write buffer))) ;; close (lambda () (when (startup #t) (if outbuf - (begin - (output outbuf) - (set! outbuf ""))) + (begin + (unbuffered-write outbuf 0 outbufsize) + (set! outbufsize 0))) (set! out-open? #f) (shutdown))) ;; flush (lambda () (when outbuf - (output outbuf) - (set! outbuf ""))) + (startup) + (unbuffered-write outbuf 0 outbufsize) + (set! outbufsize 0))) (##sys#setslot in 3 "(ssl)") (##sys#setslot out 3 "(ssl)") ;; first "reserved" slot ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/ma
Re: [Chicken-users] OpenSSL egg option defaults poll
On 23/11/14 10:32, Mario Domenech Goulart wrote: > Hi Andy, > > On Sun, 23 Nov 2014 02:57:09 + Andy Bennett > wrote: > >> + Introduces a dependency on srfi-13 for the string-copy! and >> substring/shared procedures. This is so that we can do buffer >> management with the minimal of excess copying and garbage >> collection. > > Beware that: > > * string-copy! is currently broken for some cases in CHICKEN. Master has > a fix (6b36695d94e0bd977e0d85d48438f621128e1101), but it has net been > released yet. Thanks Mario! I've looked at that patch: it seems to only affect overlapping buffers. I think, in the openssl case, the private buffer is always distinct from the user buffer. Can anyone think of any cases where that wouldn't be the case? > * substring/shared is the same as substring in CHICKEN, AFAIK. That's only called once in the corner cases so it doesn't really matter if it wastes a copy. It's just there to stop junk in the tail of the buffer being sent to the user. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi Andy, On Sun, 23 Nov 2014 02:57:09 + Andy Bennett wrote: > + Introduces a dependency on srfi-13 for the string-copy! and > substring/shared procedures. This is so that we can do buffer > management with the minimal of excess copying and garbage > collection. Beware that: * string-copy! is currently broken for some cases in CHICKEN. Master has a fix (6b36695d94e0bd977e0d85d48438f621128e1101), but it has net been released yet. * substring/shared is the same as substring in CHICKEN, AFAIK. Best wishes. Mario -- http://parenteses.org/mario ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, > IIRC we were waiting for andyjpb and company to fix the breakage introduced > by the buffering patch so we could pull in current upstream and then push > the patches or something ... Please find attached a patch to v1.6.4 of the openssl egg. This patch: + Ensures that startup is called once, with the correct "called-from-close" flag in each of the write, close and flush procedures. I think "flush" is always called when the port is supposed to be open. + Introduces a dependency on srfi-13 for the string-copy! and substring/shared procedures. This is so that we can do buffer management with the minimal of excess copying and garbage collection. + Reworks the buffered write logic to ensure that we always flush the buffer in full chunks apart from during the close and flush procedures where we just write whatever is left. I've done a minimal amount of testing and it seems to work. It seems to produce files with the same md5sum as the version without the patch so I don't think it corrupts the data. i.e. I think the buffer handling is correct. On my local machine I can't measure a speedup when downloading a static, 178MiB file or a 3.9MiB file generated with SXML / waffle, both via spiffy.. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF diff -upr v1.6.4/openssl.import.scm v1.6.4-andyjpb-fix/openssl.import.scm --- v1.6.4/openssl.import.scm 2014-11-23 02:37:31.235897645 + +++ v1.6.4-andyjpb-fix/openssl.import.scm 2014-11-23 02:13:16.085352751 + @@ -1,6 +1,6 @@ openssl.import.scm - GENERATED BY CHICKEN 4.9.0rc1 -*- Scheme -*- -(eval '(import scheme chicken foreign ports srfi-18 tcp)) +(eval '(import scheme chicken foreign ports srfi-13 srfi-18 tcp)) (##sys#register-compiled-module 'openssl (list) Binary files v1.6.4/openssl.import.so and v1.6.4-andyjpb-fix/openssl.import.so differ diff -upr v1.6.4/openssl.scm v1.6.4-andyjpb-fix/openssl.scm --- v1.6.4/openssl.scm 2014-11-23 00:07:52.324097414 + +++ v1.6.4-andyjpb-fix/openssl.scm 2014-11-23 02:31:54.004264327 + @@ -45,7 +45,7 @@ ##sys#check-string ##sys#expand-home-path)) -(use srfi-18 tcp) +(use srfi-13 srfi-18 tcp) #> #include @@ -442,11 +442,11 @@ EOF "SSL read timed out"))) buffer (out - (let* ((outbufsize (tcp-buffer-size)) - (outbuf (and outbufsize (fx> outbufsize 0) "")) - (output + (let* ((outbufmax (tcp-buffer-size)) + (outbuf (and outbufmax (fx> outbufmax 0) (make-string outbufmax))) + (outbufsize 0) + (unbuffered-write (lambda (buffer) - (startup) (when (> (##sys#size buffer) 0) ; Undefined behaviour for 0 bytes! (let loop ((offset 0) (size (##sys#size buffer))) (let ((ret (ssl-call/timeout @@ -455,30 +455,45 @@ EOF fd (tcp-write-timeout) "SSL write timed out"))) (when (fx< ret size) ; Partial write (loop (fx+ offset ret) (fx- size ret) + + (define (buffered-write data #!optional (start 0)) + (let* ((size (- (##sys#size data) start)) + (to-copy (min (- outbufmax outbufsize) size)) + (left-over (- size to-copy))) + + (string-copy! outbuf outbufsize data start (+ start to-copy)) + (set! outbufsize (+ outbufsize to-copy)) + + (if (= outbufsize outbufmax) + (begin + (unbuffered-write outbuf) + (set! outbufsize 0))) + + (if (> left-over 0) + (buffered-write data (+ start to-copy) + (make-output-port ;; write (lambda (buffer) + (startup) (if outbuf - (begin - (set! outbuf (string-append outbuf buffer)) - (when (fx>= (string-length outbuf) outbufsize) - (output outbuf) - (set! outbuf ""))) - (output buffer))) + (buffered-write buffer) + (unbuffered-write buffer))) ;; close (lambda () (when (startup #t) (if outbuf - (begin - (output outbuf) - (set! outbuf ""))) + (begin + (unbuffered-write (substring/shared outbuf 0 outbufsize)) + (set! outbufsize 0))) (set! out-open? #f) (shutdown))) ;; flush (lambda () (when outbuf - (output outbuf) - (set! outbuf ""))) + (startup) + (unbuffered-write (substring/shared outbuf 0 outbufsize)) + (set! outbufsize 0))) (##sys#setslot in 3 "(ssl)") (##sys#setslot out 3 "(ssl)") ;; first "reserved" slot Only in v1.6.4-andyjpb-fix/: openssl.scm~ Only in v1.6.4-andyjpb-fix/: .openssl.scm.swp Binary files v1.6.4/openssl.so and v1.6.4-andyjpb-fix/openssl.so differ Binary files v1.6.4/openssl-static.o and v1.6.4-andyjpb-fix/openssl-static.o differ ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi,
> that's right, but you can also try to protect against a client that
> tries to obtain information from the server side to which it isn't
So, you'd actually be protecting the association between the server and the
legitimate client against an unauthorized third party, no?
> entitled. However, selecting different cipher will help less there
> than selecting better versions of the protocol.
Neither will help, as the client will be able to decrypt the data anyhow?
Though I have the feeling we might be talking past each other ... =:-)
> Hmm, RC4 in its original form has a pretty large bias. Do you know
> if the SSL variant throws away the head of the random stream, which
> would reduce the predictability of the PRNG?
I'm pretty sure it does, so the bias is only strong, not large ... or
something ;-)
Don't get me wrong, I'm not saying RC4 is a good cipher, my point is:
neither is CBC with predictable IVs ;-)
> Anyway, CTR-based encryption modes with authentication like GCM,
> CCM, EAX and the like are probably fine if the underlying block
> cipher is strong.
Well, yes ... except that making high-performance AES constant-time in
software is difficult (impossible?), which means that on platforms without
AES-NI or similar, you get timing leaks, which is particularly bad if
that's reachable without authentication (because it is part of the
authentication). And you need TLS 1.2 for AEAD modes anyway, while explicit
IVs for CBC were introduced with 1.1, so BEAST isn't a problem there
anyhow. The padding oracle due to MAC-then-encrypt still might be, of
course ...
> >[...]
> >I don't think anyone groks the OpenSSL API ;-), but as far as I could tell,
> >roughly this should do the right thing (well, it's obviously taken from a
> >server, but the principle should be applicable in the general case):
> >[...]
>
> Huh, interesting. The documentation of OpenSSL that I have installed
> doesn't mention those TLSv1_{1,2}_{server,client}_method functions
> anywhere, but they are declared in the header files. I must have
> overlooked them. Apparently, closely studying the headers files and
> trying to divine the meaning of the functions without documentation
> is still the way to go if you want to perform any useful operation
> with OpenSSL %-]
I tend to use the online version on openssl.org ... doesn't know about
TLSv1_2_method either, even though TLS 1.2 is mentioned, but at least about
1_1! ;-)
But yeah, I don't think you can get anywhere without grepping in headers
and reading existing code that uses OpenSSL ...
> Somehow I'm tempted to start from scratch with a binding to GnuTLS
> or another library that has decent documentation ;-)
Well, from what you hear about the code quality of GnuTLS, I'm not that
sure ... ;-)
Florian
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Tue, 28 Oct 2014, Florian Zumbiehl wrote:
[...]
I am not sure I understand what you mean--you never can protect against a
client that doesn't want to protect the session, they always could just
publish the session key, or the decrypted data, or whatever. The protection
should always focus on third parties that try to undermine the security.
[...]
Hello,
that's right, but you can also try to protect against a client that tries
to obtain information from the server side to which it isn't entitled.
However, selecting different cipher will help less there than selecting
better versions of the protocol.
[...]
I don't see any serious security problems with the default. If the
configuration of the peer isn't braindead, that will negotiate a reasonably
secure cipher suite, the default connected to itself will negotiate
ECDHE-RSA-AES256-GCM-SHA384 (if the necessary server-side initialization
for ECDHE cipher suites has been done),
[...]
Implementing the necessary server-side setup for the "normal" and
elliptic-curve-based Diffie-Hellman schemes is high up on my priority list
for the OpenSSL egg, too.
[...]
plus you could argue that RC4 is
actually still more secure than CBC modes with TLS < 1.1 due to BEAST,
unless both sides implement 1/n-1 splitting or the application protocol can
not be used to perform the attack.
[...]
Hmm, RC4 in its original form has a pretty large bias. Do you know if the
SSL variant throws away the head of the random stream, which would reduce
the predictability of the PRNG?
Anyway, CTR-based encryption modes with authentication like GCM, CCM, EAX
and the like are probably fine if the underlying block cipher is strong.
[...]
I don't think anyone groks the OpenSSL API ;-), but as far as I could tell,
roughly this should do the right thing (well, it's obviously taken from a
server, but the principle should be applicable in the general case):
[...]
Huh, interesting. The documentation of OpenSSL that I have installed
doesn't mention those TLSv1_{1,2}_{server,client}_method functions
anywhere, but they are declared in the header files. I must have
overlooked them. Apparently, closely studying the headers files and trying
to divine the meaning of the functions without documentation is still the
way to go if you want to perform any useful operation with OpenSSL %-]
Somehow I'm tempted to start from scratch with a binding to GnuTLS or
another library that has decent documentation ;-)
Ciao,
Thomas
--
When C++ is your hammer, every problem looks like your thumb.
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Florian Zumbiehl scripsit: > I am not sure I understand what you mean--you never can protect against a > client that doesn't want to protect the session, they always could just > publish the session key, or the decrypted data, or whatever. The protection > should always focus on third parties that try to undermine the security. There is a difference between a malicious client designed to harm the user, and a merely ignorant client that thinks it's doing the Right Thing but isn't. It's the second kind of client that we need to defend against. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org Today an interactive brochure website, tomorrow a global content management system that leverages collective synergy to drive "outside of the box" thinking and formulate key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line. --Alex Papadimoulis ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi,
> well, if I understand some of the problems with SSL/TLS in the past
> years correctly, the fact that a specifically engineered client
> could force a brain-dead cipher suite selection actually posed a
> problem several times.
I am not sure I understand what you mean--you never can protect against a
client that doesn't want to protect the session, they always could just
publish the session key, or the decrypted data, or whatever. The protection
should always focus on third parties that try to undermine the security.
> But you are certainly right about the non-authenticated schemes,
> maybe setting the default to "HIGH:!aNULL" makes more sense?
More sense, yeah. I would still just go with the default.
> I think the idea here is to set some defaults that are reasonably
> secure, even if that means less compatible. If you want to transmit
> top-secret data you will need something entirely different from
> SSL/TLS, anyway; and if you don't care about security you can use
> the old API ;-)
I don't see any serious security problems with the default. If the
configuration of the peer isn't braindead, that will negotiate a reasonably
secure cipher suite, the default connected to itself will negotiate
ECDHE-RSA-AES256-GCM-SHA384 (if the necessary server-side initialization
for ECDHE cipher suites has been done), plus you could argue that RC4 is
actually still more secure than CBC modes with TLS < 1.1 due to BEAST,
unless both sides implement 1/n-1 splitting or the application protocol can
not be used to perform the attack.
I guess my point is: TLS is pretty fragile if you need any compatibility at
all, there are lots more things to consider besides cipher suite selection,
and there isn't even a globally valid preference order of cipher suites,
what's good for TLS 1.2 is not necessarily for TLS 1.0, what's good on
desktop machines with constant-time AES is not necessarily good on mobile
devices without, ...
> I agree, however the only easy to use presets in the OpenSSL library
> are SSLv2, SSLv3, TLS or any of them selected automatically. The
> latter has been the default so far, but that means the vulnerable
> SSLv3 can be selected, too. Judging by the documentation I'm not
> even sure whether TLS means TLS 1.0 or TLS in any supported version.
>
> It would be great if someone who really groks the OpenSSL API could
> help out here!
I don't think anyone groks the OpenSSL API ;-), but as far as I could tell,
roughly this should do the right thing (well, it's obviously taken from a
server, but the principle should be applicable in the general case):
| SSL_CTX *sslctx;
| long ssl_set_options;
| const SSL_METHOD *ssl_method;
|
| ssl_set_options=0;
| switch((SSL_VERSIONS)){
| case SSL_V3:
| ssl_method=SSLv3_server_method();
| break;
| case TLS_V10:
| ssl_method=TLSv1_server_method();
| break;
| case TLS_V11:
| ssl_method=TLSv1_1_server_method();
| break;
| case TLS_V12:
| ssl_method=TLSv1_2_server_method();
| break;
| default:
| ssl_method=SSLv23_server_method();
| ssl_set_options|=SSL_OP_NO_SSLv2;
| if(!((SSL_VERSIONS)&SSL_V3))ssl_set_options|=SSL_OP_NO_SSLv3;
| if(!((SSL_VERSIONS)&TLS_V10))ssl_set_options|=SSL_OP_NO_TLSv1;
| if(!((SSL_VERSIONS)&TLS_V11))ssl_set_options|=SSL_OP_NO_TLSv1_1;
| if(!((SSL_VERSIONS)&TLS_V12))ssl_set_options|=SSL_OP_NO_TLSv1_2;
| }
| if(!(sslctx=SSL_CTX_new(ssl_method)))die(false,"SSL_CTX_new()");
|
if((SSL_CTX_set_options(sslctx,ssl_set_options)&ssl_set_options)!=ssl_set_options)die(false,"SSL_CTX_set_options()");
> Hmm, I remember that was somehow difficult back when I first
> implemented the old API. I don't recall the reason and I'll just
> look into it again.
Yeah, I think you need memory BIOs and stuff, certainly not trivial ;-)
Florian
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Tue, 28 Oct 2014, Florian Zumbiehl wrote: [...] Regarding specific improvements: [procedure] (ssl-make-client-context* #!key ((protocol ) 'tls) ((cipher-list ) "HIGH") ((certificate-authorities ) #f) ((certificate-authority-directory ) #f) ((verify? ) #t)) Creates a new client context. Defaults to TLS protocol using only ciphers marked as strong. Loads the certificate authorities from the default directory unless other sources are specified and switches server certificate verification on by default. I'm not convinced HIGH is actually a sensible default selection (it includes ADH cipher suites, for example), or that cipher limitation is even all that important security-wise: If the handshake is not compromised, the parties should not ever select anything braindead unless one side explicitly prefers that and/or doesn't support anything better. [...] Hello, well, if I understand some of the problems with SSL/TLS in the past years correctly, the fact that a specifically engineered client could force a brain-dead cipher suite selection actually posed a problem several times. But you are certainly right about the non-authenticated schemes, maybe setting the default to "HIGH:!aNULL" makes more sense? [...] Selecting ciphers for specific security properties can be sensible, but it's difficult to find a generally applicable default that's both highly secure and widely compatible. [...] I think the idea here is to set some defaults that are reasonably secure, even if that means less compatible. If you want to transmit top-secret data you will need something entirely different from SSL/TLS, anyway; and if you don't care about security you can use the old API ;-) [...] As for protocol version selection, it would be a good idea to be able to select multiple protocol versions for compatibility with various servers that might not all be able to speak the same version, I guess TLS1.0 and greater is a reasonable default for the time being. Also, I guess it would be good to be able to explicitly select "or higher" so code specifying that will automatically support newer TLS versions as they become available. [...] I agree, however the only easy to use presets in the OpenSSL library are SSLv2, SSLv3, TLS or any of them selected automatically. The latter has been the default so far, but that means the vulnerable SSLv3 can be selected, too. Judging by the documentation I'm not even sure whether TLS means TLS 1.0 or TLS in any supported version. It would be great if someone who really groks the OpenSSL API could help out here! [...] As for certificates, it would be totally great if one could also specify the certificate itself directly, without the need to put it into a file, just in case you feel like implementing that ... ;-) [...] Hmm, I remember that was somehow difficult back when I first implemented the old API. I don't recall the reason and I'll just look into it again. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Tue, Oct 28, 2014 at 07:35:00AM +0100, Florian Zumbiehl wrote: > Hi, > > > Therefore I took another route: The existing procedures keep their > > current defaults, but there is a new set of object constructors that > > uses only keyword arguments and configures things in a more secure > > way by default. > > That seems sensible to me, in particular as making existing APIs behave in > backward incompatible ways tends to be ugly. I agree. It's a bit hairy, but maybe we can get rid of that by changing it for CHICKEN 5 so that "ssl-make-client-context" is the new one. We're breaking backwards compatibility in core as well, so it makes sense to do the same for mistakes in egg APIs too. Cheers, Peter -- http://www.more-magic.net ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, > Therefore I took another route: The existing procedures keep their > current defaults, but there is a new set of object constructors that > uses only keyword arguments and configures things in a more secure > way by default. That seems sensible to me, in particular as making existing APIs behave in backward incompatible ways tends to be ugly. Regarding specific improvements: > [procedure] (ssl-make-client-context* #!key > ((protocol ) 'tls) ((cipher-list ) "HIGH") > ((certificate-authorities ) #f) > ((certificate-authority-directory ) #f) > ((verify? ) #t)) > > Creates a new client context. Defaults to TLS protocol using only > ciphers marked as strong. Loads the certificate authorities from the > default directory unless other sources are specified and switches > server certificate verification on by default. I'm not convinced HIGH is actually a sensible default selection (it includes ADH cipher suites, for example), or that cipher limitation is even all that important security-wise: If the handshake is not compromised, the parties should not ever select anything braindead unless one side explicitly prefers that and/or doesn't support anything better. Selecting ciphers for specific security properties can be sensible, but it's difficult to find a generally applicable default that's both highly secure and widely compatible. If you control both sides, you might want to use only ciphers with forward secrecy and without MAC-then-encrypt (to avoid padding oracles), for example, but if you make that the default for the egg, you'll find many servers out there that won't know how to talk to you. As for protocol version selection, it would be a good idea to be able to select multiple protocol versions for compatibility with various servers that might not all be able to speak the same version, I guess TLS1.0 and greater is a reasonable default for the time being. Also, I guess it would be good to be able to explicitly select "or higher" so code specifying that will automatically support newer TLS versions as they become available. As for certificates, it would be totally great if one could also specify the certificate itself directly, without the need to put it into a file, just in case you feel like implementing that ... ;-) Verifying certificates by default is a very good idea indeed. Also, there are a few more things that are advisable to do for secure TLS, some of which (those that apply to the client side) are addressed by the patches that are currently blocked by andyjpb's fix, such as disabling TLS compression and requiring support for secure renegotiation from the server (though the latter may not be supported widely enough yet to make it the default, I'm not sure). On the server side, to make forward secrecy actually work, you have to set up callbacks that supply DH parameters and stuff, it's pretty ugly, but I may be able to supply code snippets if you are interested. Florian ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Mon, 27 Oct 2014, Andy Bennett wrote: [...] I'd be glad if some of you could test this out and tell me what you think about it :-) Can you give some tips for how to test this from a spiffy applications? I usually just pass in ssl-accept instead of tcp-accept. [...] Hello, actually I have very little experience with spiffy, but if it can use ssl-accept, it must use ssl-listen somewhere and that's the point that would need to be adapted. Judging by Spiffy's documentation in the Wiki you could do something like this: (define ear (ssl-listen* hostname: "localhost" port: 44344 certificate: "my-server-cert.pem" private-key: "my-server-key.pem")) (accept-loop ear ssl-accept) Beware, this snippet of code is completely untested! Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, Thanks for this Thomas! > I'd be glad if some of you could test this out and tell me what you > think about it :-) Can you give some tips for how to test this from a spiffy applications? I usually just pass in ssl-accept instead of tcp-accept. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Thu, 16 Oct 2014, Thomas Chust wrote: [...] So I would like to poll for opinions from people on this list concerning this situation. Do you think the default options in the OpenSSL egg should be "hardened"? Do you think more options should be introduced? Is compatibility with the rest of the internet a concern at all? ;-) [...] Hello, judging by the responses you wrote, there seems to be an interest in more secure defaults indeed. I looked over the OpenSSL egg API again to see how it could be improved with better default options and figured that some additional constructor parameters would be useful but there were already too many optional parameters in my opinion. Therefore I took another route: The existing procedures keep their current defaults, but there is a new set of object constructors that uses only keyword arguments and configures things in a more secure way by default. The latest SVN trunk of the OpenSSL egg includes the following additions: [parameter] ssl-default-certificate-authority-directory Holds the default directory with acceptable certificate authorities. [procedure] (ssl-make-client-context* #!key ((protocol ) 'tls) ((cipher-list ) "HIGH") ((certificate-authorities ) #f) ((certificate-authority-directory ) #f) ((verify? ) #t)) Creates a new client context. Defaults to TLS protocol using only ciphers marked as strong. Loads the certificate authorities from the default directory unless other sources are specified and switches server certificate verification on by default. [procedure] (ssl-connect* #!key (hostname ) (port ) ((protocol ) 'tls) ((cipher-list ) "HIGH") ((certificate-authorities ) #f) ((certificate-authority-directory ) #f) ((verify? ) #t)) Connects to a server using the same defaults as ssl-make-client-context* [procedure] (ssl-listen* #!key (hostname ) ((port ) #f) ((backlog ) 4) ((protocol ) 'tls) ((cipher-list ) "HIGH") (certificate ) (private-key ) ((private-key-rsa? ) #t) ((private-key-asn1? ) #f)) ((certificate-authorities ) #f) ((certificate-authority-directory ) #f) ((verify? ) #t)) Creates a listener. Defaults to TLS protocol using only ciphers marked as strong. Loads the certificate authorities from the default directory unless other sources are specified but doesn't switch client certificate verification on by default. Advertises the certificates loaded via the certificate-authorities argument to the client. I'd be glad if some of you could test this out and tell me what you think about it :-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, > IIRC we were waiting for andyjpb and company to fix the breakage introduced > by the buffering patch so we could pull in current upstream and then push > the patches or something ... Oops... sorry. I can't find the mail relating to the details of the breakage. Please can someone remind me and I'll look into it. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, > thanks for the heads up, I had totally forgotten about these > patches. Can they be found somewhere online? I'd like to take a look > again, perhaps they aren't that hard to incorporate. You probably didn't know about them yet, and they are unpublished so far, I just have pointed out the breakage to andjpb some time ago, and that we didn't want to pull in the broken code, and it seems things got stuck there. If you want to have the diffs, I should be able to post them, I don't have a clue whether there are any conflicts atm. > Incidentally I just added a ssl-set-cipher-list! to the trunk of the > egg as well, since I thought this would really be useful to > strengthen security. Yeah, that commit message on IRC reminded me, prompting me to have a look at the mailing list, and sending the mail :-) Florian ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Thu, 16 Oct 2014, Florian Zumbiehl wrote: [...] I just wanted to point out that we still have a bunch of patches lying around that among other things implement security improvements: openssl: add support for TLS 1.1 and 1.2 openssl: add functions ssl-set-reneg-legacy-server-connect!, ssl-set-no-compression!, and ssl-set-cipher-list! openssl: add support for fetching the first finished message of the connection openssl: add ssl-connect-fd [...] Hello Florian, thanks for the heads up, I had totally forgotten about these patches. Can they be found somewhere online? I'd like to take a look again, perhaps they aren't that hard to incorporate. Incidentally I just added a ssl-set-cipher-list! to the trunk of the egg as well, since I thought this would really be useful to strengthen security. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Thomas Chust scripsit: > ... and there I was thinking that was implicit in the use of SSL/TLS > in the first place ;-) Security, like privacy, exists in the individual human mind alone: die Gedanken sind frei. Beyond that, 15th century tradecraft is still the best advice: meet someone around dawn in a large open field where you can see someone else coming. In addition, it now pays to make sure there are no drones between you and the sun. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org "After all, would you consider a man without honor wealthy, even if his Dinar laid end to end would reach from here to the Temple of Toplat?" "No, I wouldn't", the beggar replied. "Why is that?" the Master asked. "A Dinar doesn't go very far these days, Master.--Kehlog Albran Besides, the Temple of Toplat is across the street." The Profit ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, I just wanted to point out that we still have a bunch of patches lying around that among other things implement security improvements: openssl: add support for TLS 1.1 and 1.2 openssl: add functions ssl-set-reneg-legacy-server-connect!, ssl-set-no-compression!, and ssl-set-cipher-list! openssl: add support for fetching the first finished message of the connection openssl: add ssl-connect-fd IIRC we were waiting for andyjpb and company to fix the breakage introduced by the buffering patch so we could pull in current upstream and then push the patches or something ... Florian ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, > Despite many valid reasons for keeping the old ones activated, I'd like > to see the old Versions dropped from the default setting. The longer > people keep them around the longer they will stay. Without my "running an actual webserver hat" on, I think I agree. Having said that, even with my "running an actual webserver hat" on, I suspect most of the problems will be on the http-client side. > Also I'd explicitly > turn *on* certificate verification, as painful as this may be. If the > ssl egg silently accepts invalid certificates it creates a false sense > of security to the user. If someone needs all these features they know > that and will turn them back on. I definitely agree with this and certainly in this case, most of the problems will occur on the http-client side rather than the spiffy side. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi, >> [...] >> Having said that, I'm not sure which clients on which operating systems >> are SSL 3.0 only. >> [...] Having read a bit more... I suspect (infer) that IE6 and possibly more things on Windows XP are the client side problems. I also suspect (infer) that the "SSL 3.0 only" (no TLS) problems are with old web *servers* rather than a proliferation of clients other than IE6. > if I understand the situation correctly, almost nobody uses SSLv3 since > it was quickly superseded by the newer TLS variants. But the initial > connection setup is similar between SSLv2 and SSLv3, while for TLS it is > entirely different and usually one uses the SSLv2 variant with > additional information that TLS is supported, if the other endpoint also > supports TLS, the protocol will then be upgraded. You can tell OpenSSL > to support only SSLv2, only SSLv3, only TLS or all three variants > together. But you cannot specifically exclude SSLv3 and still allow > SSLv2 and TLS. Thanks for the extra details. AIUI, SSLv2 and SSLv3 are more different to each other than SSLv3 and TLS1.0 ...but I suspect that's because I'm mostly familiar with the "SSLv2 variant with additional information that TLS is supported". >> [...] >> Have you seen this article by Google about TLS_FALLBACK_SCSV? >> [...] > > Yes. Whether that security measure is supported depends on the version > of the underlying SSL library, I think it is incorporated in OpenSSL > 1.0.1j. I'm unsure whether anything special needs to be done to activate > the feature. I wonder if there's a test site that will connect to a webserver and tell you if it supports that? > Personally, I think the big mess of SSL/TLS protocol versions, extension > features and cipher suites is so hideously complex by now that there > will always be some more hidden vulnerabilities %-] For anything truly > security critical I would try to use an alternative protocol with a less > convoluted design and with stronger default crypto algorithms. I agree. We'd like to run a good-and-proper SSL service but I think we'd rather run a highly compatible service when we have a choice. This trade-off starts to make sense when you take into consideration all the potential vulnerabilities that exist in even the newer versions. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Thu, 16 Oct 2014, Sascha Ziemann wrote: [...] I think it is a good idea to make TLS the default. [...] I think it is sufficient to enable SSL with a parameter or environment variable. I propose: I_DONT_CARE_ABOUT_SECURITY=yes [...] ... and there I was thinking that was implicit in the use of SSL/TLS in the first place ;-) Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Thu, Oct 16, 2014 at 09:41:29AM +0200, Christian Kellermann wrote: > Thomas Chust writes: > > So I would like to poll for opinions from people on this list > > concerning this situation. Do you think the default options in the > > OpenSSL egg should be "hardened"? Do you think more options should be > > introduced? Is compatibility with the rest of the internet a concern > > at all? ;-) > > Despite many valid reasons for keeping the old ones activated, I'd like > to see the old Versions dropped from the default setting. The longer > people keep them around the longer they will stay. Also I'd explicitly > turn *on* certificate verification, as painful as this may be. If the > ssl egg silently accepts invalid certificates it creates a false sense > of security to the user. If someone needs all these features they know > that and will turn them back on. An emphatic +1 on that from me. Cheers, Peter -- http://www.more-magic.net ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Thomas Chust writes: > So I would like to poll for opinions from people on this list > concerning this situation. Do you think the default options in the > OpenSSL egg should be "hardened"? Do you think more options should be > introduced? Is compatibility with the rest of the internet a concern > at all? ;-) Despite many valid reasons for keeping the old ones activated, I'd like to see the old Versions dropped from the default setting. The longer people keep them around the longer they will stay. Also I'd explicitly turn *on* certificate verification, as painful as this may be. If the ssl egg silently accepts invalid certificates it creates a false sense of security to the user. If someone needs all these features they know that and will turn them back on. My 2¢… Christian -- May you be peaceful, may you live in safety, may you be free from suffering, and may you live with ease. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Am 16. Oktober 2014 00:39:59 MESZ, schrieb Thomas Chust : >Do you think the default options in the OpenSSL egg >should >be "hardened"? Do you think more options should be introduced? Is >compatibility with the rest of the internet a concern at all? ;-) I think it is a good idea to make TLS the default. I did it yesterday on my web server. I think it is sufficient to enable SSL with a parameter or environment variable. I propose: I_DONT_CARE_ABOUT_SECURITY=yes ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
On Thu, 16 Oct 2014, Andy Bennett wrote: [...] Having said that, I'm not sure which clients on which operating systems are SSL 3.0 only. [...] Hello Andy, if I understand the situation correctly, almost nobody uses SSLv3 since it was quickly superseded by the newer TLS variants. But the initial connection setup is similar between SSLv2 and SSLv3, while for TLS it is entirely different and usually one uses the SSLv2 variant with additional information that TLS is supported, if the other endpoint also supports TLS, the protocol will then be upgraded. You can tell OpenSSL to support only SSLv2, only SSLv3, only TLS or all three variants together. But you cannot specifically exclude SSLv3 and still allow SSLv2 and TLS. [...] Have you seen this article by Google about TLS_FALLBACK_SCSV? [...] Yes. Whether that security measure is supported depends on the version of the underlying SSL library, I think it is incorporated in OpenSSL 1.0.1j. I'm unsure whether anything special needs to be done to activate the feature. Personally, I think the big mess of SSL/TLS protocol versions, extension features and cipher suites is so hideously complex by now that there will always be some more hidden vulnerabilities %-] For anything truly security critical I would try to use an alternative protocol with a less convoluted design and with stronger default crypto algorithms. Ciao, Thomas -- When C++ is your hammer, every problem looks like your thumb. ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] OpenSSL egg option defaults poll
Hi Thomas! > So I would like to poll for opinions from people on this list concerning > this situation. Do you think the default options in the OpenSSL egg > should be "hardened"? Do you think more options should be introduced? Is > compatibility with the rest of the internet a concern at all? ;-) We run Spiffy with SSL on our live site at https://www.knodium.com/ Our users are typically in educational environments where the provided software is not always of the latest version so we'd like to have as wide support as possible for clients that might visit our site. Having said that, I'm not sure which clients on which operating systems are SSL 3.0 only. In this case we're using OpenSSL on the server side (http-client may differ) and given that we control what we use there, the thing that matters is the population of web browsers that require SSL 3.0 in order to work with HTTPS sites. Have you seen this article by Google about TLS_FALLBACK_SCSV? http://googleonlinesecurity.blogspot.co.uk/2014/10/this-poodle-bites-exploiting-ssl-30.html More info: https://www.openssl.org/~bodo/ssl-poodle.pdf https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 Again, I'm not sure which clients support that yet, especially amongst the older ones which do support TLS but are still old and therefore might not get updates. This approach doesn't work unless both sides support it. >From the Google article it sounds like it might be worth us implementing TLS_FALLBACK-SCSV and waiting to hear the results of the test in which they disable SSL 3.0. Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
