Re: [openssl-users] X509 Version changes?

[Jim Carroll]

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 read it back, the version is set then set to 0.  Is this expected
(GIGO) behavior?



begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14

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

[Jim Carroll]

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 declarations file. The
M2Crypto swig declaration file uses some pretty sophisticated directives,
and I think one of them was getting in the way.  Specifically, I believe it
was a conflict with %inline %{ ... %} and the swig pre-processor.

We're using SWIG 3.0.1, and we're compiling a small list of bug fixes for
them as well (mostly with how they handle certain Microsoft specific
extensions).  After we finish the port of M2Crypto, we'll submit to them as
well.

> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Dr. Stephen Henson
> Sent: Thursday, July 21, 2016 3:00 PM
> To: openssl-users@openssl.org
> Subject: 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 understand your suggestion).
> >
> 
> Well there are various things going on underneath which can be hard to
> follow
> if you aren't used to them. Here's a bit more detail about what is
> going on.
> 
> Initially we just include the necessary headers:
> 
> #include 
> #include 
> 
> ASN.1 encode/decode routines generally use a structure name. We have
> STACK_OF(X509) but no name for that so we can make one up which I call
> SEQ_CERT:
> 
> typedef STACK_OF(X509) SEQ_CERT;
> 
> The next bit defines an ASN.1 module structure which says the SEQ_CERT
> is
> a SEQUENCE OF X509:
> 
> ASN1_ITEM_TEMPLATE(SEQ_CERT) =
> ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, SeqCert, X509)
> ASN1_ITEM_TEMPLATE_END(SEQ_CERT)
> 
> Here SEQ_CERT is the structure name which that macro defines as a
> SEQUENCE OF
> X509. The "SeqCert" is just a string that is used as a name in the
> definition:
> it can be anything.
> 
> Now that's all very well but it doesn't actually define any functions.
> The bit
> that does that is this:
> 
> IMPLEMENT_ASN1_FUNCTIONS(SEQ_CERT)
> 
> This implements four functions but we're only interested in the encode
> and
> decode ones which look like this:
> 
>  int i2d_SEQ_CERT(SEQ_CERT *a, unsigned char **pp);
>  TYPE *d2i_SEQ_CERT(SEQ_CERT **a, unsigned char **pp, long length);
> 
> These behave like regular ASN.1 functions you pass in SEQ_CERT: which
> is
> STACK_OF(X509) to the i2d_SEQ_CERT and it encodes the result as a
> SEQUENCE
> OF X509 which is the same format as the original.
> 
> Similarly you can decode using d2i_SEQ_CERT() and get back a
> STACK_OF(X509).
> 
> If you have this in a separate module you can declare the new functions
> (e.g.
> in a header file) with:
> 
> DECLARE_ASN1_FUNCTIONS(SEQ_CERT)
> 
> Hope that helps. If you have any further problems let me know.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14

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

[Dr. Stephen Henson]

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 understand your suggestion).
> 

Well there are various things going on underneath which can be hard to follow
if you aren't used to them. Here's a bit more detail about what is going on.

Initially we just include the necessary headers:

#include 
#include 

ASN.1 encode/decode routines generally use a structure name. We have
STACK_OF(X509) but no name for that so we can make one up which I call
SEQ_CERT:

typedef STACK_OF(X509) SEQ_CERT;

The next bit defines an ASN.1 module structure which says the SEQ_CERT is
a SEQUENCE OF X509:

ASN1_ITEM_TEMPLATE(SEQ_CERT) =
ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, SeqCert, X509)
ASN1_ITEM_TEMPLATE_END(SEQ_CERT)

Here SEQ_CERT is the structure name which that macro defines as a SEQUENCE OF
X509. The "SeqCert" is just a string that is used as a name in the definition:
it can be anything.

Now that's all very well but it doesn't actually define any functions. The bit
that does that is this:

IMPLEMENT_ASN1_FUNCTIONS(SEQ_CERT)

This implements four functions but we're only interested in the encode and
decode ones which look like this:

 int i2d_SEQ_CERT(SEQ_CERT *a, unsigned char **pp);
 TYPE *d2i_SEQ_CERT(SEQ_CERT **a, unsigned char **pp, long length);

These behave like regular ASN.1 functions you pass in SEQ_CERT: which is
STACK_OF(X509) to the i2d_SEQ_CERT and it encodes the result as a SEQUENCE
OF X509 which is the same format as the original.

Similarly you can decode using d2i_SEQ_CERT() and get back a STACK_OF(X509).

If you have this in a separate module you can declare the new functions (e.g.
in a header file) with:

DECLARE_ASN1_FUNCTIONS(SEQ_CERT)

Hope that helps. If you have any further problems let me know.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
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

[Dr. Stephen Henson]

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 your suggestion).
> 
> I've spent more time reading ASN1 headers since then, and I'm starting to
> get a glimmer of understanding of whats/what. I'm now circling back to your
> solution and I think I'm getting on top of the swig issue.
> 

I'd be interested in knowing more details of the swig problems you had. If it
helps you can just include my code snippet in a separate C source file and
then just use the i2d/d2i functions in the swig wrapper itself.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Carl Heyendal]

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...@openssl.org] On Behalf Of Dr. 
Stephen Henson
Sent: July-21-16 10:34 AM
To: openssl-users@openssl.org
Subject: [Newsletter] 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 this error:
> 
> # ./client3 192.168.1.99
> Enter PEM pass phrase:
> connecting to 192.168.1.99:16001
> ** client3.c:77 Error connecting SSL object 1024:error:04091068:rsa 
> routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
> 1024:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad 
> signature:s3_clnt.c:2004:
> 
> The app uses the same private key and certificate in both cases.
> 

It could be a compiler bug on the embedded platform. Does it pass "make test"?

Have you tried it with optimisation turned off?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitment of Fortinet to Fortinet's customers 
or partners. Thank you. *** 


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Salz, Rich]

> 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 been this way forever. There was an open ticket about removing all 
fixed-sized limits, I think.  But I doubt that will happen.



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Jakob Bohm]

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 choice, right. And that doesn't make it a bad decision
either.

+1


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?  That sounds doubly buggy as it will be too
high a limit for some configurations and too low a limit for
some other configurations.

The situation would be different for limits that would depend
on the sanity of remote values (such as the key length in a
client certificate sent to a server checking the limit or the
key length in a server certificate sent to a client checking
the limit).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Salz, Rich]

> 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 make it a bad decision
> either.

+1
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Erwann Abalea]

> 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 modified to accept client key exchange messages up to 4kB.
Server A is configured with a 2048bits RSA key.

Client A connects to Server A, initiates the TLS handshake, receives the 
certificate, properly generates a 2048bits client key exchange message (using 
RSA key exchange), sends the message (about 260 octets); Server A accepts it 
and will do the job.

Client B connects to Server A, initiates the TLS handshake, receives the 
certificate, but for whatever reason decides to send a client key exchange 
message composed of what could be a 16kb RSA block (about 2056 bytes); Server A 
will accept the message, but will refuse to perform the RSA decryption (because 
it’s larger than the modulus length).

I don’t see where the harm can hide. There’s no more CPU eaten, network 
transfer has already happened at this moment, memory is already allocated.

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 make it a bad 
decision either.

-- 
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

[Jim Carroll]

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 reading ASN1 headers since then, and I'm starting to
get a glimmer of understanding of whats/what. I'm now circling back to your
solution and I think I'm getting on top of the swig issue.

Thanks for all your help.

> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Dr. Stephen Henson
> Sent: Thursday, July 21, 2016 9:53 AM
> To: openssl-users@openssl.org
> Subject: 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 suggested will do that: if you call i2d_SEQ_CERT (or
> whatever you called it) that will work. That wraps the whole lot in a
> SEQUENCE
> header which is the same as the original. That is it is a SEQUENCE OF
> 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?
> > Is there a better way?
> >
> 
> It depends on what the other side expects. If you just do that that and
> EOF
> signals the and of the last certificate you'll be fine. If you append
> additional data afterwards then you need to mark the last certificate
> somehow.
> The certificate sequence version prepends the data with the length of
> all the
> certificates so it automatically handles that.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14

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

[Dr. Stephen Henson]

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 this error:
> 
> # ./client3 192.168.1.99
> Enter PEM pass phrase:
> connecting to 192.168.1.99:16001
> ** client3.c:77 Error connecting SSL object
> 1024:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
> 1024:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad 
> signature:s3_clnt.c:2004:
> 
> The app uses the same private key and certificate in both cases.
> 

It could be a compiler bug on the embedded platform. Does it pass "make test"?

Have you tried it with optimisation turned off?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Salz, Rich]

> 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" from 
consuming all your CPU with a large key?

Who needs 16K RSA keys, such that openssl by default should support that for 
everyone?
-- 
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

[Salz, Rich]

> 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/listinfo/openssl-users

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

[Carl Heyendal]

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 phrase:
connecting to 192.168.1.99:16001
** client3.c:77 Error connecting SSL object
1024:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
1024:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad 
signature:s3_clnt.c:2004:

The app uses the same private key and certificate in both cases.

As a test I used s_client on both platforms to see whether it's a problem with 
the app, and it too fails with the same error on the embedded target but makes 
a connection on the Ubuntu machinejust like the app.

Something I observed on a wireshark trace is that depending on what platform 
the app is running on, in the 'Client Hello' exchange the app advertises a much 
smaller set of cipher suites on the Ubuntu machine than on the embedded target 
app. Consequently the server chooses a different cipher suite in both 
situations. This puzzles me and not sure if it's related to my problem.

Worth noting the version of openssl on the Ubuntu machine which is the platform 
that works, is older than the version for the embedded target board.

Not using TLSv2.

Appreciate any help or a nudge on how to debug this.

/carl h.



***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitment of Fortinet to Fortinet's customers 
or partners. Thank you. *** 


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Gupta, Saurabh]

> 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 the ssl/s3_srvr.c because that will 
"permit appropriate message length".


I came across this functionality when I compared the code of openssl-1.0.1p and 
openssl-1.0.2e.


Regards,
Saurabh



From: openssl-users  on behalf of 
openssl-users-requ...@openssl.org 
Sent: Thursday, July 21, 2016 6:38 PM
To: openssl-users@openssl.org
Subject: openssl-users Digest, Vol 20, Issue 18

Send openssl-users mailing list submissions to
openssl-users@openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
openssl-users-requ...@openssl.org

You can reach the person managing the list at
openssl-users-ow...@openssl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Openssl software failure for RSA 16K modulus (Salz, Rich)
   2. Re: Openssl software failure for RSA 16K modulus (Salz, Rich)
   3. Re: Help  finding replacement for ASN1_seq_unpack_X509
  (Jim Carroll)
   4. Re: [openssl-users]   Helpfinding replacement for
  ASN1_seq_unpack_X509 (Salz, Rich)
   5. Re: Openssl software failure for RSA 16K modulus (Erwann Abalea)
   6. Re: Openssl software failure for RSA 16K modulus (Salz, Rich)


--

Message: 1
Date: Thu, 21 Jul 2016 12:15:15 +
From: "Salz, Rich" 
To: "openssl-users@openssl.org" 
Subject: Re: [openssl-users] Openssl software failure for RSA 16K
modulus
Message-ID:

Content-Type: text/plain; charset="Windows-1252"


> 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 make trade-offs.  Who uses a 16K RSA key?


--

Message: 2
Date: Thu, 21 Jul 2016 12:17:44 +
From: "Salz, Rich" 
To: "openssl-users@openssl.org" 
Subject: Re: [openssl-users] Openssl software failure for RSA 16K
modulus
Message-ID:

Content-Type: text/plain; charset="Windows-1252"

> 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




--

Message: 3
Date: Thu, 21 Jul 2016 08:52:24 -0400
From: "Jim Carroll" 
To: 
Subject: Re: [openssl-users] Help   finding replacement for
ASN1_seq_unpack_X509
Message-ID: <00e201d1e34e$ba83f760$2f8be620$@carroll.com>

 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
changes, but a few were in the are of getting rid of some ASN1 processing
(which happens to be our weakest point of understanding).

We're left with porting the final bit -- which is related to X509 cert
handling.  Here's a sample use. The caller builds up the call with a the
following 'psuedo-sequence'. get_der() is the function we are working on
finishing.

X508* load_cert_bio(char* filename) {
BIO* bio = BIO_new_file(filename, "r");
return PEM_read_bio_X509(bio, NULL, NULL, NULL);
}

unsigned char* get_der(int* len_out) {
X509* cert = load_cert_bio("x509.pem");
X509* ca = load_cert_bio("ca.pem");

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);
}

The ASN1_seq_pack_X509 was a macro -- and has been removed.


> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Salz, Rich
> Sent: Thursday, July 21, 2016 4:35 AM
> To: 

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

[Dr. Stephen Henson]

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 blobs one after the other.
> Yes, what you thought to do is fine. :)

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.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
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

[Dr. Stephen Henson]

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 suggested will do that: if you call i2d_SEQ_CERT (or
whatever you called it) that will work. That wraps the whole lot in a SEQUENCE
header which is the same as the original. That is it is a SEQUENCE OF 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?
> Is there a better way?
> 

It depends on what the other side expects. If you just do that that and EOF
signals the and of the last certificate you'll be fine. If you append
additional data afterwards then you need to mark the last certificate somehow.
The certificate sequence version prepends the data with the length of all the
certificates so it automatically handles that.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
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

[Salz, Rich]

> 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

[Jim Carroll]

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
> 
> 
> > 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 to do is fine. :)
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14

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

[Salz, Rich]

>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/listinfo/openssl-users

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

[Erwann Abalea]

> 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 every application at risk of a 
DoS, because these applications won’t suddenly use a 16k RSA key.
Anyway, OpenSSL 1.0.2+ now sets some limits on message sizes (defensive), some 
tradeoffs have to be done on those limits. According to some sources (NIST and 
ECRYPT II), 16k RSA provides an equivalent security level of a 512bits ECC key.
-- 
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

[Salz, Rich]

>   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 to do is fine. :)
-- 
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

[Jim Carroll]

 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
changes, but a few were in the are of getting rid of some ASN1 processing
(which happens to be our weakest point of understanding).

We're left with porting the final bit -- which is related to X509 cert
handling.  Here's a sample use. The caller builds up the call with a the
following 'psuedo-sequence'. get_der() is the function we are working on
finishing.

X508* load_cert_bio(char* filename) {
BIO* bio = BIO_new_file(filename, "r");
return PEM_read_bio_X509(bio, NULL, NULL, NULL);
}

unsigned char* get_der(int* len_out) {
X509* cert = load_cert_bio("x509.pem");
X509* ca = load_cert_bio("ca.pem");

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);
}

The ASN1_seq_pack_X509 was a macro -- and has been removed.


> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Salz, Rich
> Sent: Thursday, July 21, 2016 4:35 AM
> To: openssl-users@openssl.org
> Subject: 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 fine.
> But if you're sending a SEQUENCE OF certificates then you need to wrap
> it in an ASN1/DER container. For example, Netscape Cert Sequence
> 
> Can you post a code snippet?
> 
> 
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14

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

[Salz, Rich]

> 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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Salz, Rich]

> 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 make trade-offs.  Who uses a 16K RSA key?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Erwann Abalea]

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 à 10:32, Gupta, Saurabh 
> a écrit :

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 routines:ssl3_get_message:excessive message 
size:s3_both.c:417:


This error is coming while using AES128-SHA as a cipher and tls1/1_1/1_2 
protocols. It's working fine with ssl3 protocol.

Note:
1. This issue, I didn't face for the openssl-1.0.1p/e version.

Can you please confirm. is this known issue?
if it is the known issue. Can you please share that fix?

Regards,
Saurabh
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[Gupta, Saurabh]

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 routines:ssl3_get_message:excessive message 
size:s3_both.c:417:


This error is coming while using AES128-SHA as a cipher and tls1/1_1/1_2 
protocols. It's working fine with ssl3 protocol.

Note:
1. This issue, I didn't face for the openssl-1.0.1p/e version.

Can you please confirm. is this known issue?
if it is the known issue. Can you please share that fix?


Regards,
Saurabh
-- 
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

[Salz, Rich]

> 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 fine.  But if you're 
sending a SEQUENCE OF certificates then you need to wrap it in an ASN1/DER 
container. For example, Netscape Cert Sequence

Can you post a code snippet?


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users