1: I didn't get it, Why this behaviour is not coming for other ciphers while
doing the server/client handshake?
It should fail for other ciphers also.
Ciphers: working
DHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
.. etc
Ciphers: Not working
AES128-SHA
AES256-SHA
.. etc
Protocols:
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 and
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 declarat
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 un
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 yo
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 [mailto:openssl-users-boun...@openss
> 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 has
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 cho
> 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 m
> 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.
Server A code is
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 readi
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
> 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 side
> 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: https://mta.openssl.org/mailman/
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 pass
> 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 in
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
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 sug
> 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
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
>
>
> >
>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: https://mta.openssl.org/mailman/l
> 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 don’t suddenly put e
> 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
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
change
> 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 mai
> 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 to
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 à
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 routi
> 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 fi
29 matches
Mail list logo