Openssl software failure for RSA 16K modulus

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

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 <server_ip>: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
Reply | Threaded
Open this post in threaded view
|

Re: Openssl software failure for RSA 16K modulus

Erwann Abalea-4
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 <[hidden email]> 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 <server_ip>: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
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: 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: [hidden email] Twitter: RichSalz


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Openssl software failure for RSA 16K modulus

Erwann Abalea-4

> Le 21 juil. 2016 à 14:17, Salz, Rich <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: Openssl software failure for RSA 16K modulus

Gupta, Saurabh
In reply to this post by 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 <[hidden email]> on behalf of [hidden email] <[hidden email]>
Sent: Thursday, July 21, 2016 6:38 PM
To: [hidden email]
Subject: openssl-users Digest, Vol 20, Issue 18
 
Send openssl-users mailing list submissions to
        [hidden email]

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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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]       Help    finding 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 +0000
From: "Salz, Rich" <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: [openssl-users] Openssl software failure for RSA 16K
        modulus
Message-ID:
        <[hidden email]>
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 +0000
From: "Salz, Rich" <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: [openssl-users] Openssl software failure for RSA 16K
        modulus
Message-ID:
        <[hidden email]>
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: [hidden email] Twitter: RichSalz




------------------------------

Message: 3
Date: Thu, 21 Jul 2016 08:52:24 -0400
From: "Jim Carroll" <[hidden email]>
To: <[hidden email]>
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 [[hidden email]] On
> Behalf Of Salz, Rich
> Sent: Thursday, July 21, 2016 4:35 AM
> To: [hidden email]
> 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
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P@0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0@17AT97)N86P@5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0@WLWEEI%F@E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P@8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0@04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3@8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q@1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42@U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0@17AT97)N86P@0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38@0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4@16UA:6P@0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI@8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST@83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K@N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F@-Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M@9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0@075T:&5N=&EC871I
M;VX@86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI@9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G@U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1@8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P@8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1@0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C@1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID@HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0@L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0@4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C$Q,C4R,C1:
M,",&"2J&2(;W#0$)!#$6!!1G&[GL6/=H8LZE9M4)L7L&;?<.K#!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P@8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38@0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4@16UA:6P@0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0@4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0"BA-SZ*7/VI,VOREMEIW/;NJ!T.(Q,&_+LZM3[,K57Q>;>/_E:B,?4
MK5#@,W&"P\/'6&9N(0O:&\E9$LLW&L4A&HFUP*--6&QWBNO"Q&@@SIXKRKY!
M_1ADXBJEW(_'N=2L<O%!9/VQ^P]?>'::Q/1SE_GHOFK1&0]"5Q.5WG@#>A65
MB(_+) A!06%L^,:81&8%&!ZR+=BE5G.6@!ENZ? 9F%CZ(<"+? HBSP6%VV8?
MTAS31B5,U\:SOL4_RM%C>8G1EAU^KEX8F\F8/,E_>XVZIV_@N7TL:@M3&I0Q
J=3SK\27,?_:X'&P\D7@_/_32#280-K>N"UZHE-(Y;\OR3/=C````````
`
end



------------------------------

Message: 4
Date: Thu, 21 Jul 2016 12:57:09 +0000
From: "Salz, Rich" <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: [openssl-users]    Help    finding replacement     for
        ASN1_seq_unpack_X509
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="Windows-1252"


>            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. :)


------------------------------

Message: 5
Date: Thu, 21 Jul 2016 12:31:56 +0000
From: Erwann Abalea <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: [openssl-users] Openssl software failure for RSA 16K
        modulus
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"


> Le 21 juil. 2016 ? 14:17, Salz, Rich <[hidden email]> 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.

------------------------------

Message: 6
Date: Thu, 21 Jul 2016 13:08:52 +0000
From: "Salz, Rich" <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: [openssl-users] Openssl software failure for RSA 16K
        modulus
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"


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

------------------------------

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
[hidden email]
https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

End of openssl-users Digest, Vol 20, Issue 18
*********************************************

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: Openssl software failure for RSA 16K modulus

Erwann Abalea-4
In reply to this post by Salz, Rich

> Le 21 juil. 2016 à 15:08, Salz, Rich <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: Openssl software failure for RSA 16K modulus

Jakob Bohm-7
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
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: Openssl software failure for RSA 16K modulus

Gupta, Saurabh
In reply to this post by Gupta, Saurabh

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:

tls1/tls1_1/tls1_2


2: if anyway I want to use 16k modulus, Do we have solution to avoid this issue so that it won't harm to other application or create any new attack?

3: ECC cipher is not my main concerned.

4: I didn't face any issue like memory utilisation or CPU utilisation is more if I'm running more than one client in the case of 16k modulus.

Regards,
Saurabh

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Openssl software failure for RSA 16K modulus

Salz, Rich
> 2: if anyway I want to use 16k modulus, Do we have solution to avoid this issue so that it won't harm to other application or create any new attack?

No.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Openssl software failure for RSA 16K modulus

Gupta, Saurabh
In reply to this post by Gupta, Saurabh

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


We have cryptographic accelerators on cavium platforms which minimize CPU usage. So our customers are looking for 16K support.


Regards,
Saurabh

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Openssl software failure for RSA 16K modulus

Erwann Abalea-4
In reply to this post by Gupta, Saurabh
Bonjour,

Le 22 juil. 2016 à 08:44, Gupta, Saurabh <[hidden email]> a écrit :

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

Because the key exchange is performed using DHE or ECDHE here, and parameters are much smaller than your server authentication key.
If you configure a 16k DH group and choose to use DHE as the key exchange algorithm, you’ll surely fall under the same error.

Ciphers: Not working
AES128-SHA
AES256-SHA
...... etc


RSA key exchange.

2: if anyway I want to use 16k modulus, Do we have solution to avoid this issue so that it won't harm to other application or create any new attack?

3: ECC cipher is not my main concerned.


You should be concerned about the security provided by your choices, and not pure raw numbers.

4: I didn't face any issue like memory utilisation or CPU utilisation is more if I'm running more than one client in the case of 16k modulus.

Your measuring tools are bad, change them ;)
Signing with a 16k RSA key is way slower than with a 2048bits key, and again way slower than using ECC.

According to NIST, equivalent « security levels »:
RSA15360, DH15360, ECC512 (or 521)
RSA7680, DH7680, ECC384
RSA3072, DH3072, ECC256

Measurements done on my machine:
Signing with ECDSA over the P521 curve is 600x faster than signing with a 15kRSA key.
Performing a key exchange with ECDH over the P521 curve is about 180x faster than decrypting with a 15k RSA key.

Using the P384 curve and a 7kRSA key, the numbers are 180x faster and 50x faster.
Using the P256 curve and a 4kRSA key, numbers are about 90x faster for both operations.

I don’t have any measurements for DH key exchange, but it should cost twice more than doing a private RSA operation, and also impacts the client, and when used within TLS it comes in addition to an RSA signing operation.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Openssl software failure for RSA 16K modulus

Salz, Rich
In reply to this post by Gupta, Saurabh
> We have cryptographic accelerators on cavium platforms which minimize CPU usage. So our customers are looking for 16K support.

Well, sorry, but by default most other sides won't be able to use them.  Not sure anything else to say.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users