Re: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509

On Thu, Jul 21, 2016, Jim Carroll wrote: > > I ran into problems with swig when I tried to deploy you suggestion. Your > solution was slick pre-processor magic's and I was having difficulty > reversing the magic to troubleshoot swig (and I was a little shy about > admitting I didn't understand

Re: [openssl-users] [Newsletter] Re: Same openssl app behaves differently depending on platform

Turned out to be optimization as you suggested. Once I turned it off the app connected on the embedded target. Good one Steve. I had forgotten how optimization mucks things up from time to time. Thanks /carl h. -Original Message- From: openssl-users

Re: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509

On Thu, Jul 21, 2016, Jim Carroll wrote: > Steve, > > I ran into problems with swig when I tried to deploy you suggestion. Your > solution was slick pre-processor magic's and I was having difficulty > reversing the magic to troubleshoot swig (and I was a little shy about > admitting I didn't

Re: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509

I was just typing a reply to your previous message asking for a bit of clarification and this message just came through -- answered every single one of my questions ! To answer your question about the swig changes, I was able to solve the problem by moving your code to the top of the swig

Re: [openssl-users] X509 Version changes?

I've run into what appears to be a change to defaults between 0.9.8 and 1.1.0, and I wanted to make sure it's not a bug we've introduced. While reviewing unittests, we see that calls to X509_REQ_new() generate an X509 object with the version set to -1. When we write this object to a PEM file

Re: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509

> Thanks Rich! You're welcome. Getting M2Crypto moved to 1.1 is a *great* project. Thanks. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509

> Actually that is including a SEQUENCE header and not just the DER blobs. So if > the result must be compatible with the original format the snippet I > suggested would be appropriate here. Thanks for the correction. -- openssl-users mailing list To unsubscribe:

Re: [openssl-users] Openssl software failure for RSA 16K modulus

> Instead of raising the limit of client key exchange message length more than > 2048, why can't we add the > "ssl3_check_client_hello" functionality in the ssl/s3_srvr.c because that > will "permit appropriate message length". The DoS issue is still there. How can you prevent the "other

Re: [openssl-users] Same openssl app behaves differently depending on platform

On Thu, Jul 21, 2016, Carl Heyendal wrote: > I have an app that uses openssl to connect to a server on a different > machine. In one case on my Ubuntu machine the app has no problem getting a > secure connection. But when I recompile the same app for an embedded target > board and run it I get

Re: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509

Steve, I ran into problems with swig when I tried to deploy you suggestion. Your solution was slick pre-processor magic's and I was having difficulty reversing the magic to troubleshoot swig (and I was a little shy about admitting I didn't understand your suggestion). I've spent more time

[openssl-users] Openssl software failure for RSA 16K modulus

This issue, I'm facing for openssl-1.0.2e/g/h version. Run openssl server: Used 16K Certificate and Key ./openssl s_server -cert sercert16384.pem -key server16384 Run openssl client: ./openssl s_client -connect :port_number -cipher AES128-SHA -tls1 ERROR 139812135450280:error:1408E098:SSL

Re: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509

> Would it be acceptable to just iterate the stack elements, passing each X509 > through i2d_X509 and appending the results -- would that generate valid > DER? Maybe. It depends on what the receiver is expecting. If it's willing to read a set of certs until it hits EOF (or equivalent) that's

Re: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509

On Wed, Jul 20, 2016, Jim Carroll wrote: > Thanks muchI have a corollary question if you don't mind. In OpenSSL > 1.1.0, what is the accepted procedure to convert a STACK_OF(X509) to DER? > It depends on what you mean by "to DER" and what the other ends is expecting. The code snipped I

Re: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509

On Thu, Jul 21, 2016, Salz, Rich wrote: > > > STACK_OF(X509)* stack = sk_x509_new_null(); > > sk_x509_push(stack, cert); > > sk_x509_push(stack, ca); > > > > return ASN1_seq_pack_X509(stack, i2d_X509, NULL, len_out); > > Okay, so your just pushing two DER-format

Re: [openssl-users] Openssl software failure for RSA 16K modulus

> By raising the limit, you don't suddenly put every application at risk of a > DoS, > because these applications won't suddenly use a 16k RSA key. Instead of raising the limit of client key exchange message length more than 2048, why can't we add the "ssl3_check_client_hello" functionality

[openssl-users] Same openssl app behaves differently depending on platform

I have an app that uses openssl to connect to a server on a different machine. In one case on my Ubuntu machine the app has no problem getting a secure connection. But when I recompile the same app for an embedded target board and run it I get this error: # ./client3 192.168.1.99 Enter PEM

Re: [openssl-users] Openssl software failure for RSA 16K modulus

Largest accepted client key exchange message length seems to be set to 2048 bytes. Key exchange for an RSA16k is slightly larger than that (exactly 2048 bytes of pure crypto payload, plus a few bytes of overhead). OpenSSL is too conservative here. Cordialement, Erwann Abalea Le 21 juil. 2016

Re: [openssl-users] Openssl software failure for RSA 16K modulus

> Largest accepted client key exchange message length seems to be set to 2048 > bytes. > Key exchange for an RSA16k is slightly larger than that (exactly 2048 bytes > of pure crypto payload, plus a few bytes of overhead). > OpenSSL is too conservative here. Why not use an ECC key? We have

Re: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509

We are porting M2Crypto which is a python swig wrapper around OpenSSL. It currently supports OpenSSL 0.9.8 and we are porting it to 1.1.0. The 1.1.0 branch is really cool (clean, elegant code), but there were a few refactoring's that affected M2Crypto. Most were trivial getter/setter type

Re: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509

> STACK_OF(X509)* stack = sk_x509_new_null(); > sk_x509_push(stack, cert); > sk_x509_push(stack, ca); > > return ASN1_seq_pack_X509(stack, i2d_X509, NULL, len_out); Okay, so your just pushing two DER-format blobs one after the other. Yes, what you thought

Re: [openssl-users] Openssl software failure for RSA 16K modulus

>By raising the limit, you don’t suddenly put every application at risk of a >DoS, > because these applications won’t suddenly use a 16k RSA key. Yes we do, because the other side could send a key, not local config. -- openssl-users mailing list To unsubscribe:

Re: [openssl-users] Openssl software failure for RSA 16K modulus

> We have to make trade-offs. Who uses a 16K RSA key? Let me add some clarification. Is it worth putting every application that uses OpenSSL at risk for a DoS attack with a 16K RSA key? -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz -- openssl-users

Re: [openssl-users] Openssl software failure for RSA 16K modulus

> Le 21 juil. 2016 à 14:17, Salz, Rich a écrit : > >> We have to make trade-offs. Who uses a 16K RSA key? > > Let me add some clarification. Is it worth putting every application that > uses OpenSSL at risk for a DoS attack with a 16K RSA key? By raising the limit, you

Re: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509

Thanks Rich! > -Original Message- > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > Behalf Of Salz, Rich > Sent: Thursday, July 21, 2016 8:57 AM > To: openssl-users@openssl.org > Subject: Re: [openssl-users] Help finding replacement for > ASN1_seq_unpack_X509 > > > >

Re: [openssl-users] Openssl software failure for RSA 16K modulus

> Again, I’m not saying using a 16kRSA key is a good idea. It’s not a good idea, > one should really consider ECC instead (both for performance and network > reasons). But keeping this 2048 bytes limit is not a security decision. It’s > the > result of a trade-off choice, right. And that doesn't

Re: [openssl-users] Openssl software failure for RSA 16K modulus

> Wait, is OpenSSL "sanity checking" a message size dictated by the same ends > local configuration against a fixed arbitrary limit rather than a limit > computed > from that local configuration? Yup. Call it a limitation of C, if you want. "#define MAX_..." is just too hard to avoid. It

Re: [openssl-users] Openssl software failure for RSA 16K modulus

> Le 21 juil. 2016 à 15:08, Salz, Rich a écrit : > >> By raising the limit, you don’t suddenly put every application at risk of a >> DoS, >> because these applications won’t suddenly use a 16k RSA key. > > Yes we do, because the other side could send a key, not local config.

Re: [openssl-users] Openssl software failure for RSA 16K modulus

On 21/07/2016 17:28, Salz, Rich wrote: Again, I’m not saying using a 16kRSA key is a good idea. It’s not a good idea, one should really consider ECC instead (both for performance and network reasons). But keeping this 2048 bytes limit is not a security decision. It’s the result of a trade-off