From juriarte at redhat.com  Mon Apr  2 17:51:20 2018
From: juriarte at redhat.com (Jon Uriarte)
Date: Mon, 2 Apr 2018 19:51:20 +0200
Subject: [openssl-users] CSR verify failure
In-Reply-To: <A7597522-B1AD-47E4-8929-6A9DE3856F36@carillon.ca>
References: <CAB0_ssconc7WE7tuVE9sZ1rDGPeWRbqB5t08HiCBNKEMkwFOmA@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801CBF4EF07@prvxmb03.microfocus.com>
 <CAB0_sscYE0xX_RrVx4QbxY-mr5DHXYiJozVjrEK8GWipCyio7Q@mail.gmail.com>
 <071BD49D-F44C-4B15-8A78-9635CF576673@felipegasper.com>
 <CAB0_sscFpF_i-VPRqAOMGGcrVEpxxjWCUegBc_hPp0Lg=UPynw@mail.gmail.com>
 <85E7748F-44FF-4246-937E-36C9B091DDCE@felipegasper.com>
 <A7597522-B1AD-47E4-8929-6A9DE3856F36@carillon.ca>
Message-ID: <CAB0_ssdwCZOBMTNrUEEP+MOv0Sy_3-CbV6mVRRocGpJB4LGzTQ@mail.gmail.com>

Hey all,

Thanks a lot for your comments, they helped me to realize that I was
configuring/doing something wrong.

I was hitting the CSR creation issues on a virtual machine, and the source
of the wrong signature seems to be related to the virtualization type I was
using.
When using qemu the issue is reproduced, and when using kvm it is not
reproduced. CSR verification and crt creation is working since I changed to
kvm
virtualization type in the hypervisor.

Thanks again

Jon


On Mon, Mar 26, 2018 at 8:00 PM, Dave Coombs <dcoombs at carillon.ca> wrote:

> Yeah, it looks like the signature is just wrong.  Even setting aside the
> question of padding, I used rsautl -verify -raw on the signature using the
> CSR's public key, and I would expect to see a pair of sequence tags (0x30)
> with sensible lengths somewhere inside, and I don't.
>
> hulk:/tmp $ openssl req -in CSR.pem -pubkey -noout -out pubkey.pem
>
> (not shown: asn1parse to find the offset of the start of the signature)
>
> hulk:/tmp $ openssl asn1parse -in CSR.pem -i -strparse 390 -out
> /tmp/sig.bin > /dev/null 2>&1
>
> hulk:/tmp $ openssl rsautl -verify -pubin -inkey pubkey.pem -in sig.bin
> -raw | xxd
> 00000000: def6 b025 c8eb d0b0 02b4 dd99 cfe6 81fa  ...%............
> 00000010: 12cb 3085 5102 aa40 84c6 d510 222b 8648  ..0.Q.. at ...."+.H
> 00000020: c891 03eb 7440 0ced d43b 4fcf 498b ae80  ....t at ...;O.I...
> 00000030: 0822 3ad1 d77c 3f45 db41 c0ce 6fe4 7390  .":..|?E.A..o.s.
> 00000040: 4b87 db0a b87a 688a 1f5f 1061 e7cd 3b44  K....zh.._.a..;D
> 00000050: a4eb cca6 d4b4 7a8e eb4e 3642 309b 7101  ......z..N6B0.q.
> 00000060: 81fb fbfb 44a5 5b81 8d61 38ec 7785 aced  ....D.[..a8.w...
> 00000070: 9035 add7 b1d6 1ffd a0dc 58ec 700c 8ae9  .5........X.p...
> 00000080: f994 33c5 ffa8 70be 1db2 dc86 0587 b70c  ..3...p.........
> 00000090: 185d 7b61 226e 939a 0e6a 41ca 3fa0 ff74  .]{a"n...jA.?..t
> 000000a0: 1ca1 1abd 9203 91a1 0750 07d4 a8da 1114  .........P......
> 000000b0: 80f9 2cf8 9d22 309c 203c c92e 6e20 4bd3  ..,.."0. <..n K.
> 000000c0: 2a98 f1e4 9d9a f0c2 5411 2a0d 9931 1ca8  *.......T.*..1..
> 000000d0: 5f14 ec51 cbe1 e37f 5d6e 683e 2dab b4ed  _..Q....]nh>-...
> 000000e0: 21c5 8632 4b03 af1a 2b66 35f7 9e2a c326  !..2K...+f5..*.&
> 000000f0: 0ebc 84ad 664f b882 83eb 8c5a dc03 6eb4  ....fO.....Z..n.
>
> Contrast with what I pulled out from a known-good sha256WithRSAEncryption
> CSR:
>
> hulk:/tmp $ openssl rsautl -verify -pubin -inkey pubkey2.pem -in sig2.bin
> -raw | xxd
> 00000000: 0001 ffff ffff ffff ffff ffff ffff ffff  ................
> 00000010: ffff ffff ffff ffff ffff ffff ffff ffff  ................
> 00000020: ffff ffff ffff ffff ffff ffff ffff ffff  ................
> 00000030: ffff ffff ffff ffff ffff ffff ffff ffff  ................
> 00000040: ffff ffff ffff ffff ffff ffff ffff ffff  ................
> 00000050: ffff ffff ffff ffff ffff ffff ffff ffff  ................
> 00000060: ffff ffff ffff ffff ffff ffff ffff ffff  ................
> 00000070: ffff ffff ffff ffff ffff ffff ffff ffff  ................
> 00000080: ffff ffff ffff ffff ffff ffff ffff ffff  ................
> 00000090: ffff ffff ffff ffff ffff ffff ffff ffff  ................
> 000000a0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
> 000000b0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
> 000000c0: ffff ffff ffff ffff ffff ffff 0030 3130  .............010
> 000000d0: 0d06 0960 8648 0165 0304 0201 0500 0420  ...`.H.e.......
> 000000e0: 52fc 1687 6e70 15a1 7c40 1e1a e083 0c74  R...np..|@.....t
> 000000f0: f6bb 761b 9656 4df7 5edd 02ac f414 bd5b  ..v..VM.^......[
>
> Where you can clearly see the two sequence tags after the end of the
> padding.
>
> hulk:/tmp $ openssl rsautl -verify -pubin -inkey pubkey2.pem -in sig2.bin
> | openssl asn1parse -inform der -i
>     0:d=0  hl=2 l=  49 cons: SEQUENCE
>     2:d=1  hl=2 l=  13 cons:  SEQUENCE
>     4:d=2  hl=2 l=   9 prim:   OBJECT            :sha256
>    15:d=2  hl=2 l=   0 prim:   NULL
>    17:d=1  hl=2 l=  32 prim:  OCTET STRING      [HEX DUMP]:
> 52FC16876E7015A17C401E1AE0830C74F6BB761B96564DF75EDD02ACF414BD5B
>
> As to how this *happened*, I'm afraid I've no idea.
>
>   -Dave
>
>
>
> > On Mar 26, 2018, at 12:15, Felipe Gasper <felipe at felipegasper.com>
> wrote:
> >
> > I see the same errors with 1.0.2n.
> >
> > Going by posts I see out-and-about about this error, there seem to be
> two possibilities:
> >
> > 1) There?s an RSA padding scheme mismatch. Maybe your openssl.cnf has
> something nonstandard, e.g., raw padding rather than PKCS1?
> >
> > 2) The signature is simply incorrect. It?s been a while since I did
> this, but I *believe* you could check this by extracting the bytes for the
> first-nested SEQUENCE from the ASN.1 structure, get the signature for that
> blob against your private key, then compare that to the CSR?s stored
> signature. They should be the same.
> >
> > Also, did you verify that the modulus and exponent as stored in the CSR
> match up against your private key file?
> >
> > -F
> >
> >> On Mar 26, 2018, at 11:55 AM, Jon Uriarte <juriarte at redhat.com> wrote:
> >>
> >> Sure, here it is:
> >>
> >> $ cat CSR.csr
> >> -----BEGIN CERTIFICATE REQUEST-----
> >> MIIChzCCAW8CAQAwQjELMAkGA1UEBhMCWFgxFTATBgNVBAcMDERlZmF1bHQgQ2l0
> >> eTEcMBoGA1UECgwTRGVmYXVsdCBDb21wYW55IEx0ZDCCASIwDQYJKoZIhvcNAQEB
> >> BQADggEPADCCAQoCggEBAOJuhJcO1eqtGE8Yc7P4cSgSwlwyuAe8AYzseGCqwAEY
> >> XHVdAXaPspJcRyP2ndz2AmYfytPPogFEWPnf86WKyaNHp4Aan2LEo0Z345Zqhb8G
> >> rApR6hqdAyqATGNrgYchtVZNo1JN2bRgY/MUXqdunfS3W33LEJwg0b7tf4KBHPLw
> >> lOqkyWo75xvMROcMISRX+k5NbckAsXkX5H52lryYQrirzqgHR8C8Bqe4pzYHLsqA
> >> 2Sw6F+emfOxTGmqhN6O2WQBryP5/9CpySHST1oG5wDtPqZ2EhE1gdpeQDPjHRiaU
> >> kITBlcsAQY0LNUEqqKnqc/0IgZJGAxocxRhbh908ow0CAwEAAaAAMA0GCSqGSIb3
> >> DQEBCwUAA4IBAQBxhvGIfkvJZjZqB/B2ZEtVcODj/BhfmSjUlcQ74NdSZC5CUslc
> >> y7ozJQiAXiRibaGOcPmeIGY6FNbLECWT/Fr2eciozvadDM+Klp92cqT3ZowuSjX0
> >> UV+1zfy2pu5OBtKfbGs0pBlsC6bLKyVH2s4yoYluBEeGRuVv69HmZXOGE6H0SvHj
> >> LOV2puEkwtZcM/xq0uszDHfKVrbLp+kT+m0OIgNRUDngkcpdp9P1W8tMLVY5m8ar
> >> h8ebVGxVF7ZtYihi6LPVaRcJgNyoawntxhhiX/3rmzq3pavbcrxV3+j6rSLxvw2z
> >> eeHSCU6jTmFbKK/KPR9TUlJycelzKP1zAZCV
> >> -----END CERTIFICATE REQUEST-----
> >>
> >>
> >> Jon
> >>
> >> On Mon, Mar 26, 2018 at 5:49 PM, Felipe Gasper <felipe at felipegasper.com>
> wrote:
> >> But what is the actual PEM of the CSR?
> >>
> >> It should look like:
> >>
> >> -----BEGIN CERTIFICATE REQUEST-----
> >> ...
> >> -----END CERTIFICATE REQUEST-----
> >>
> >> -FG
> >>
> >>> On Mar 26, 2018, at 11:47 AM, Jon Uriarte <juriarte at redhat.com> wrote:
> >>>
> >>> Thanks for your replies.
> >>>
> >>> I'm creating the CSR with the default values.
> >>>
> >>> $ openssl req -noout -text -in CSR.csr
> >>> Certificate Request:
> >>>    Data:
> >>>        Version: 0 (0x0)
> >>>        Subject: C=XX, L=Default City, O=Default Company Ltd
> >>>        Subject Public Key Info:
> >>>            Public Key Algorithm: rsaEncryption
> >>>                Public-Key: (2048 bit)
> >>>                Modulus:
> >>>                    00:e2:6e:84:97:0e:d5:ea:ad:18:4f:18:73:b3:f8:
> >>>                    71:28:12:c2:5c:32:b8:07:bc:01:8c:ec:78:60:aa:
> >>>                    c0:01:18:5c:75:5d:01:76:8f:b2:92:5c:47:23:f6:
> >>>                    9d:dc:f6:02:66:1f:ca:d3:cf:a2:01:44:58:f9:df:
> >>>                    f3:a5:8a:c9:a3:47:a7:80:1a:9f:62:c4:a3:46:77:
> >>>                    e3:96:6a:85:bf:06:ac:0a:51:ea:1a:9d:03:2a:80:
> >>>                    4c:63:6b:81:87:21:b5:56:4d:a3:52:4d:d9:b4:60:
> >>>                    63:f3:14:5e:a7:6e:9d:f4:b7:5b:7d:cb:10:9c:20:
> >>>                    d1:be:ed:7f:82:81:1c:f2:f0:94:ea:a4:c9:6a:3b:
> >>>                    e7:1b:cc:44:e7:0c:21:24:57:fa:4e:4d:6d:c9:00:
> >>>                    b1:79:17:e4:7e:76:96:bc:98:42:b8:ab:ce:a8:07:
> >>>                    47:c0:bc:06:a7:b8:a7:36:07:2e:ca:80:d9:2c:3a:
> >>>                    17:e7:a6:7c:ec:53:1a:6a:a1:37:a3:b6:59:00:6b:
> >>>                    c8:fe:7f:f4:2a:72:48:74:93:d6:81:b9:c0:3b:4f:
> >>>                    a9:9d:84:84:4d:60:76:97:90:0c:f8:c7:46:26:94:
> >>>                    90:84:c1:95:cb:00:41:8d:0b:35:41:2a:a8:a9:ea:
> >>>                    73:fd:08:81:92:46:03:1a:1c:c5:18:5b:87:dd:3c:
> >>>                    a3:0d
> >>>                Exponent: 65537 (0x10001)
> >>>        Attributes:
> >>>            a0:00
> >>>    Signature Algorithm: sha256WithRSAEncryption
> >>>         71:86:f1:88:7e:4b:c9:66:36:6a:07:f0:76:64:4b:55:70:e0:
> >>>         e3:fc:18:5f:99:28:d4:95:c4:3b:e0:d7:52:64:2e:42:52:c9:
> >>>         5c:cb:ba:33:25:08:80:5e:24:62:6d:a1:8e:70:f9:9e:20:66:
> >>>         3a:14:d6:cb:10:25:93:fc:5a:f6:79:c8:a8:ce:f6:9d:0c:cf:
> >>>         8a:96:9f:76:72:a4:f7:66:8c:2e:4a:35:f4:51:5f:b5:cd:fc:
> >>>         b6:a6:ee:4e:06:d2:9f:6c:6b:34:a4:19:6c:0b:a6:cb:2b:25:
> >>>         47:da:ce:32:a1:89:6e:04:47:86:46:e5:6f:eb:d1:e6:65:73:
> >>>         86:13:a1:f4:4a:f1:e3:2c:e5:76:a6:e1:24:c2:d6:5c:33:fc:
> >>>         6a:d2:eb:33:0c:77:ca:56:b6:cb:a7:e9:13:fa:6d:0e:22:03:
> >>>         51:50:39:e0:91:ca:5d:a7:d3:f5:5b:cb:4c:2d:56:39:9b:c6:
> >>>         ab:87:c7:9b:54:6c:55:17:b6:6d:62:28:62:e8:b3:d5:69:17:
> >>>         09:80:dc:a8:6b:09:ed:c6:18:62:5f:fd:eb:9b:3a:b7:a5:ab:
> >>>         db:72:bc:55:df:e8:fa:ad:22:f1:bf:0d:b3:79:e1:d2:09:4e:
> >>>         a3:4e:61:5b:28:af:ca:3d:1f:53:52:52:72:71:e9:73:28:fd:
> >>>         73:01:90:95
> >>>
> >>>
> >>> $ openssl asn1parse -dump -in CSR.csr
> >>>    0:d=0  hl=4 l= 647 cons: SEQUENCE
> >>>    4:d=1  hl=4 l= 367 cons: SEQUENCE
> >>>    8:d=2  hl=2 l=   1 prim: INTEGER           :00
> >>>   11:d=2  hl=2 l=  66 cons: SEQUENCE
> >>>   13:d=3  hl=2 l=  11 cons: SET
> >>>   15:d=4  hl=2 l=   9 cons: SEQUENCE
> >>>   17:d=5  hl=2 l=   3 prim: OBJECT            :countryName
> >>>   22:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :XX
> >>>   26:d=3  hl=2 l=  21 cons: SET
> >>>   28:d=4  hl=2 l=  19 cons: SEQUENCE
> >>>   30:d=5  hl=2 l=   3 prim: OBJECT            :localityName
> >>>   35:d=5  hl=2 l=  12 prim: UTF8STRING        :Default City
> >>>   49:d=3  hl=2 l=  28 cons: SET
> >>>   51:d=4  hl=2 l=  26 cons: SEQUENCE
> >>>   53:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
> >>>   58:d=5  hl=2 l=  19 prim: UTF8STRING        :Default Company Ltd
> >>>   79:d=2  hl=4 l= 290 cons: SEQUENCE
> >>>   83:d=3  hl=2 l=  13 cons: SEQUENCE
> >>>   85:d=4  hl=2 l=   9 prim: OBJECT            :rsaEncryption
> >>>   96:d=4  hl=2 l=   0 prim: NULL
> >>>   98:d=3  hl=4 l= 271 prim: BIT STRING
> >>>      0000 - 00 30 82 01 0a 02 82 01-01 00 e2 6e 84 97 0e d5
>  .0.........n....
> >>>      0010 - ea ad 18 4f 18 73 b3 f8-71 28 12 c2 5c 32 b8 07
>  ...O.s..q(..\2..
> >>>      0020 - bc 01 8c ec 78 60 aa c0-01 18 5c 75 5d 01 76 8f
>  ....x`....\u].v.
> >>>      0030 - b2 92 5c 47 23 f6 9d dc-f6 02 66 1f ca d3 cf a2
>  ..\G#.....f.....
> >>>      0040 - 01 44 58 f9 df f3 a5 8a-c9 a3 47 a7 80 1a 9f 62
>  .DX.......G....b
> >>>      0050 - c4 a3 46 77 e3 96 6a 85-bf 06 ac 0a 51 ea 1a 9d
>  ..Fw..j.....Q...
> >>>      0060 - 03 2a 80 4c 63 6b 81 87-21 b5 56 4d a3 52 4d d9
>  .*.Lck..!.VM.RM.
> >>>      0070 - b4 60 63 f3 14 5e a7 6e-9d f4 b7 5b 7d cb 10 9c
>  .`c..^.n...[}...
> >>>      0080 - 20 d1 be ed 7f 82 81 1c-f2 f0 94 ea a4 c9 6a 3b
> .............j;
> >>>      0090 - e7 1b cc 44 e7 0c 21 24-57 fa 4e 4d 6d c9 00 b1
>  ...D..!$W.NMm...
> >>>      00a0 - 79 17 e4 7e 76 96 bc 98-42 b8 ab ce a8 07 47 c0
>  y..~v...B.....G.
> >>>      00b0 - bc 06 a7 b8 a7 36 07 2e-ca 80 d9 2c 3a 17 e7 a6
>  .....6.....,:...
> >>>      00c0 - 7c ec 53 1a 6a a1 37 a3-b6 59 00 6b c8 fe 7f f4
>  |.S.j.7..Y.k....
> >>>      00d0 - 2a 72 48 74 93 d6 81 b9-c0 3b 4f a9 9d 84 84 4d
>  *rHt.....;O....M
> >>>      00e0 - 60 76 97 90 0c f8 c7 46-26 94 90 84 c1 95 cb 00
>  `v.....F&.......
> >>>      00f0 - 41 8d 0b 35 41 2a a8 a9-ea 73 fd 08 81 92 46 03
>  A..5A*...s....F.
> >>>      0100 - 1a 1c c5 18 5b 87 dd 3c-a3 0d 02 03 01 00 01
> ....[..<.......
> >>>  373:d=2  hl=2 l=   0 cons: cont [ 0 ]
> >>>  375:d=1  hl=2 l=  13 cons: SEQUENCE
> >>>  377:d=2  hl=2 l=   9 prim: OBJECT            :sha256WithRSAEncryption
> >>>  388:d=2  hl=2 l=   0 prim: NULL
> >>>  390:d=1  hl=4 l= 257 prim: BIT STRING
> >>>      0000 - 00 71 86 f1 88 7e 4b c9-66 36 6a 07 f0 76 64 4b
>  .q...~K.f6j..vdK
> >>>      0010 - 55 70 e0 e3 fc 18 5f 99-28 d4 95 c4 3b e0 d7 52
>  Up...._.(...;..R
> >>>      0020 - 64 2e 42 52 c9 5c cb ba-33 25 08 80 5e 24 62 6d
>  d.BR.\..3%..^$bm
> >>>      0030 - a1 8e 70 f9 9e 20 66 3a-14 d6 cb 10 25 93 fc 5a   ..p..
> f:....%..Z
> >>>      0040 - f6 79 c8 a8 ce f6 9d 0c-cf 8a 96 9f 76 72 a4 f7
>  .y..........vr..
> >>>      0050 - 66 8c 2e 4a 35 f4 51 5f-b5 cd fc b6 a6 ee 4e 06
>  f..J5.Q_......N.
> >>>      0060 - d2 9f 6c 6b 34 a4 19 6c-0b a6 cb 2b 25 47 da ce
>  ..lk4..l...+%G..
> >>>      0070 - 32 a1 89 6e 04 47 86 46-e5 6f eb d1 e6 65 73 86
>  2..n.G.F.o...es.
> >>>      0080 - 13 a1 f4 4a f1 e3 2c e5-76 a6 e1 24 c2 d6 5c 33
>  ...J..,.v..$..\3
> >>>      0090 - fc 6a d2 eb 33 0c 77 ca-56 b6 cb a7 e9 13 fa 6d
>  .j..3.w.V......m
> >>>      00a0 - 0e 22 03 51 50 39 e0 91-ca 5d a7 d3 f5 5b cb 4c
>  .".QP9...]...[.L
> >>>      00b0 - 2d 56 39 9b c6 ab 87 c7-9b 54 6c 55 17 b6 6d 62
>  -V9......TlU..mb
> >>>      00c0 - 28 62 e8 b3 d5 69 17 09-80 dc a8 6b 09 ed c6 18
>  (b...i.....k....
> >>>      00d0 - 62 5f fd eb 9b 3a b7 a5-ab db 72 bc 55 df e8 fa
>  b_...:....r.U...
> >>>      00e0 - ad 22 f1 bf 0d b3 79 e1-d2 09 4e a3 4e 61 5b 28
>  ."....y...N.Na[(
> >>>      00f0 - af ca 3d 1f 53 52 52 72-71 e9 73 28 fd 73 01 90
>  ..=.SRRrq.s(.s..
> >>>      0100 - 95                                                .
> >>>
> >>>
> >>> Jon
> >>>
> >>> On Mon, Mar 26, 2018 at 5:36 PM, Michael Wojcik <
> Michael.Wojcik at microfocus.com> wrote:
> >>> I just tried the same commands on my system, using 1.0.2n, and didn't
> have any problems (as I'd expect).
> >>>
> >>> What's the output of openssl asn1parse -dump -in CSR.csr?
> >>>
> >>> --
> >>> Michael Wojcik
> >>> Distinguished Engineer, Micro Focus
> >>>
> >>>
> >>> --
> >>> 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 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180402/1a75518c/attachment-0001.html>

From openssl at openssl.org  Tue Apr  3 13:46:24 2018
From: openssl at openssl.org (OpenSSL)
Date: Tue, 3 Apr 2018 13:46:24 +0000
Subject: [openssl-users] OpenSSL version 1.1.1 pre release 4 published
Message-ID: <20180403134624.GA18668@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.1.1 pre release 4 (beta)
   ===========================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 4 has now
   been made available. For details of changes and known issues see the
   release notes at:

        https://www.openssl.org/news/openssl-1.1.1-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The beta release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.1-pre4.tar.gz
      Size: 8259067
      SHA1 checksum: 28d83c6441d269660ca1571331bb830867b082d4
      SHA256 checksum: df2d5fcc2a878525611c75b9e9116fbcfbce8d9b96419a16eda5fb11ecc428f6

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.1-pre4.tar.gz
    openssl sha256 openssl-1.1.1-pre4.tar.gz

   Please download and check this beta release as soon as possible.
   To report a bug, open an issue on GitHub:

    https://github.com/openssl/openssl/issues

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaw4CRAAoJENnE0m0OYESR8/gH+wRA1A8TQnwUr9/keW8SGZrg
wxhgEh3q04yYTL7yGYMWn53TDLJR1TJN3viEKtS9vZ7/EIfytb7Q/Sf+dlEpy3GP
Fe5QWQu76DakiF5HHKVoVmcNyObA1sdNzqagxz/XhYkhUdjToOlqDhT0lkPg42ps
lidX68jqvZx2DfE5yjsHp4HzHwLsXVPcOILarX0OOIeG7mVS1k9fIqnVFsajnOhR
KJxMoyJ59pos0hsjA6ZHcjMpcaeXFEUYCqpPQYP/EqQz5h5q456HRovempB+GRM8
yUWAPAgaqfTlOz5Jx5+1SxFbKqFc+/Rkx2M3zpa15SuJ6R7cHZiS/JLlBXF+LiQ=
=x0tg
-----END PGP SIGNATURE-----

From KHenderson at verisign.com  Tue Apr  3 15:00:48 2018
From: KHenderson at verisign.com (Henderson, Karl)
Date: Tue, 3 Apr 2018 15:00:48 +0000
Subject: [openssl-users] SSL_CTX_set_tlsext_ticket_key_cb - creating a valid
 ctx and hmac ctx in callback.
Message-ID: <486FC113-96A6-49DB-A70D-93C538F956C6@verisign.com>

I know there may be a million reasons people can tell me not to do this, but for some dome code, I need to have a client contact a server with an RFC5077 ticket (not one previously sent from the server) with a propriety payload in the IV. I?d like to use the key_name in the ticket to get a key. And then I?d like to use this and create a valid context and hmac so that I can have a 0-RTT startup.

 

Are there any good examples on how this might be done?

 

Note, I?m running 1.1.0 with opaqueness, so I?ll need to use CTX accessor functions.

 

Thanks,

Karl 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180403/6d8bb5e3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5263 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180403/6d8bb5e3/attachment.bin>

From noreply81 at t-online.de  Tue Apr  3 23:09:41 2018
From: noreply81 at t-online.de (Guido)
Date: Wed, 4 Apr 2018 01:09:41 +0200
Subject: [openssl-users] SSL_CTX_set_tlsext_ticket_key_cb - creating a
 validctx and hmac ctx in callback.
In-Reply-To: <486FC113-96A6-49DB-A70D-93C538F956C6@verisign.com>
References: <486FC113-96A6-49DB-A70D-93C538F956C6@verisign.com>
Message-ID: <1f3V3d-20NKVc0@fwd12.t-online.de>

Vielen Dank!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Gesendet von Mail f?r Windows 10

Von: Henderson, Karl via openssl-users
Gesendet: Dienstag, 3. April 2018 17:02
An: openssl-users at openssl.org
Betreff: [openssl-users] SSL_CTX_set_tlsext_ticket_key_cb - creating a validctx and hmac ctx in callback.

I know there may be a million reasons people can tell me not to do this, but for some dome code, I need to have a client contact a server with an RFC5077 ticket (not one previously sent from the server) with a propriety payload in the IV. I?d like to use the key_name in the ticket to get a key. And then I?d like to use this and create a valid context and hmac so that I can have a 0-RTT startup.

Are there any good examples on how this might be done?

Note, I?m running 1.1.0 with opaqueness, so I?ll need to use CTX accessor functions.

Thanks,
Karl 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180404/e31e1dd8/attachment.html>

From John.Eichenberger at Honeywell.com  Tue Apr  3 22:55:06 2018
From: John.Eichenberger at Honeywell.com (Eichenberger, John)
Date: Tue, 3 Apr 2018 22:55:06 +0000
Subject: [openssl-users] Correct the check of RSA_FLAG_SIGN_VER
Message-ID: <BN6PR07MB3553B5B834436F685450D434F6A50@BN6PR07MB3553.namprd07.prod.outlook.com>

Honeywell Internal

I think I have an answer for why this commit needed to be reverted:
Author:                Dr. Stephen Henson <steve at openssl.org>
Author date:      2 years ago (12/20/2015 10:18:43 AM)
Commit date:    2 years ago (12/20/2015 11:27:03 AM)
Commit hash:    6656ba7152dfe4bba865e327dd362ea08544aa80
Children:              1c7de36f62
Parent(s):            17592f323a

Don't check RSA_FLAG_SIGN_VER.

Reviewed-by: Richard Levitte <levitte at openssl.org>

The change made in that commit was to simply remove the attempt to check for the RSA_FLAG_SIGN_VER flag. But that?s not what is wrong with this code that required changing.
The change should be to add ?meth? prior to flags:

@@ -84,7 +89,7 @@ int RSA_sign(int type, const unsigned char *m, unsigned int m_len,
         return 0;
     }
#endif
-    if ((rsa->flags & RSA_FLAG_SIGN_VER) && rsa->meth->rsa_sign) {
+    if ((rsa->meth->flags & RSA_FLAG_SIGN_VER) && rsa->meth->rsa_sign) {
         return rsa->meth->rsa_sign(type, m, m_len, sigret, siglen, rsa);
     }
     /* Special case: SSL signature, just check the length */
@@ -293,7 +298,7 @@ int RSA_verify(int dtype, const unsigned char *m, unsigned int m_len,
                const unsigned char *sigbuf, unsigned int siglen, RSA *rsa)
{

-    if ((rsa->flags & RSA_FLAG_SIGN_VER) && rsa->meth->rsa_verify) {
+    if ((rsa->meth->flags & RSA_FLAG_SIGN_VER) && rsa->meth->rsa_verify) {
         return rsa->meth->rsa_verify(dtype, m, m_len, sigbuf, siglen, rsa);
     }

--

-Ike-
  John Eichenberger
Intermec by Honeywell
Principal Engineer: Sustaining Engineering
425.921.4507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180403/7dbc8ee0/attachment-0001.html>

From levitte at openssl.org  Wed Apr  4 02:42:46 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 04 Apr 2018 04:42:46 +0200 (CEST)
Subject: [openssl-users] Correct the check of RSA_FLAG_SIGN_VER
In-Reply-To: <BN6PR07MB3553B5B834436F685450D434F6A50@BN6PR07MB3553.namprd07.prod.outlook.com>
References: <BN6PR07MB3553B5B834436F685450D434F6A50@BN6PR07MB3553.namprd07.prod.outlook.com>
Message-ID: <20180404.044246.480798974021499228.levitte@openssl.org>

In message <BN6PR07MB3553B5B834436F685450D434F6A50 at BN6PR07MB3553.namprd07.prod.outlook.com> on Tue, 3 Apr 2018 22:55:06 +0000, "Eichenberger, John" <John.Eichenberger at Honeywell.com> said:

John.Eichenberger> Honeywell Internal
John.Eichenberger> 
John.Eichenberger> I think I have an answer for why this commit needed to be reverted:
John.Eichenberger> 
John.Eichenberger> Author: Dr. Stephen Henson <steve at openssl.org>
John.Eichenberger> Author date: 2 years ago (12/20/2015 10:18:43 AM)
John.Eichenberger> Commit date: 2 years ago (12/20/2015 11:27:03 AM)
John.Eichenberger> Commit hash: 6656ba7152dfe4bba865e327dd362ea08544aa80
John.Eichenberger> Children: 1c7de36f62
John.Eichenberger> Parent(s): 17592f323a
John.Eichenberger> 
John.Eichenberger> Don't check RSA_FLAG_SIGN_VER.
John.Eichenberger> 
John.Eichenberger> Reviewed-by: Richard Levitte <levitte at openssl.org>
John.Eichenberger> 
John.Eichenberger> The change made in that commit was to simply remove
John.Eichenberger> the attempt to check for the RSA_FLAG_SIGN_VER flag.
John.Eichenberger> But that?s not what is wrong with this code that
John.Eichenberger> required changing. The change should be to add
John.Eichenberger> ?meth? prior to flags:

Well, not quite, actually.  We can easily study the code prior to this
change by looking at the 1.0.2 source.

1. in RSA_new_method(), which is used to create new instances of the
   RSA structure, there's this line:

    ret->flags = ret->meth->flags & ~RSA_FLAG_NON_FIPS_ALLOW;

   So that makes the check of rsa->flags valid, no need to go via
   rsa->meth

2. In rsa.h (crypto/rsa/rsa.h in 1.0.2), you'll find this comment in
   the middle of the definition of rsa_meth_st

    /*
     * New sign and verify functions: some libraries don't allow arbitrary
     * data to be signed/verified: this allows them to be used. Note: for
     * this to work the RSA_public_decrypt() and RSA_private_encrypt() should
     * *NOT* be used RSA_sign(), RSA_verify() should be used instead. Note:
     * for backwards compatibility this functionality is only enabled if the
     * RSA_FLAG_SIGN_VER option is set in 'flags'.
     */

   Do note the note on backward compatibility...  you see, there were
   versions of OpenSSL where the fields 'rsa_sign' and 'rsa_verify'
   didn't exist (they appeared in OpenSSL 0.9.5), so for the sake of
   allowing older applications to work with the newer OpenSSL without
   recompilation, we required all new RSA method implementations to
   use that flag to have the 'rsa_sign' and 'rsa_verify' functions
   used.  Without that flag, those functions were assumed not to
   exist, that the RSA method structure was pre-0.9.5.  However, this
   was somewhere in 2000.

   Fast forward to 2015, when we were starting to make certain types
   opaque, and someone noticed this flag still hanging around, and we
   figured that 0.9.5 is long gone, and 1.0.1 was a year away from its
   end of life, and we figured that the reason to have this flag at
   all was a matter of years long past, it was time to simply drop its
   use.  It had grown to become irrelevant a long time ago.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From KHenderson at verisign.com  Wed Apr  4 11:44:57 2018
From: KHenderson at verisign.com (Henderson, Karl)
Date: Wed, 4 Apr 2018 11:44:57 +0000
Subject: [openssl-users] SSL_CTX_set_tlsext_ticket_key_cb - creating a
 valid ctx and hmac ctx in callback.
In-Reply-To: <1D3BE66C-FEF0-4472-960C-4A6393E6DA3D@dukhovni.org>
References: <486FC113-96A6-49DB-A70D-93C538F956C6@verisign.com>
 <1D3BE66C-FEF0-4472-960C-4A6393E6DA3D@dukhovni.org>
Message-ID: <E40C930A-02A9-4BF1-9E46-EEBC731D1304@verisign.com>

Thanks for the response - yes, I do understand I'm re-purposing this mechanism in a creative way. At this time, it's just for experimental purposes.

?On 4/3/18, 5:34 PM, "Viktor Dukhovni" <viktor at dukhovni.org> wrote:

    
    
    > On Apr 3, 2018, at 11:00 AM, Henderson, Karl via openssl-users <openssl-users at openssl.org> wrote:
    > 
    > I know there may be a million reasons people can tell me not to do this, but for some dome code, I need to have a client contact a server with an RFC5077 ticket (not one previously sent from the server) with a propriety payload in the IV. I?d like to use the key_name in the ticket to get a key. And then I?d like to use this and create a valid context and hmac so that I can have a 0-RTT startup.
    
    This is too sketchy to provide a meaningful response.  Session tickets are a mechanism for a server to *export* its session state to clients, allowing the server to do stateless session resumption.  They are not a mechanism for anything else, and other uses are likely to be fragile, and possibly insecure.  Too much creativity here is risky.
    
    > Are there any good examples on how this might be done?
    
    Probably not.
    
    -- 
    	Viktor.
    
    


From artlemuel at gmail.com  Wed Apr  4 15:38:06 2018
From: artlemuel at gmail.com (Jerry L)
Date: Wed, 4 Apr 2018 11:38:06 -0400
Subject: [openssl-users] make test failure OpenSSL 1.0.2o
Message-ID: <CAFVWEzVQCk0ybOoS13VrE+fr8JcpHikf7Ak1WL+9gW3vghfWCQ@mail.gmail.com>

Compiled OpenSSL on AIX 7.1.5.2 using gcc, I used the same Configuration
options that I have been using for 5 years:

    Configure aix-gcc zlib fips shared

When running make test, I am getting the following:

 test_bad_dtls

    ../util/shlib_wrap.sh .bad_dtls_test
test_fatalerr
     ../utils/shlib_wrap.sh  ./fatalerrtest ../app/server.pem
../apps/server.pem
SSL_accept() failed -1,   1
804401144:error:140800FF:SSL routines:ssl3_accept:unknown
state:s3_srvr.c:869:

I ran the test on my 1.0.2n build and did not encounter this error.

Kind of lost here.  Any ideas?

Art
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180404/ea883716/attachment.html>

From matt at openssl.org  Wed Apr  4 16:03:28 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 4 Apr 2018 17:03:28 +0100
Subject: [openssl-users] make test failure OpenSSL 1.0.2o
In-Reply-To: <CAFVWEzVQCk0ybOoS13VrE+fr8JcpHikf7Ak1WL+9gW3vghfWCQ@mail.gmail.com>
References: <CAFVWEzVQCk0ybOoS13VrE+fr8JcpHikf7Ak1WL+9gW3vghfWCQ@mail.gmail.com>
Message-ID: <56ace7d2-2a10-b2db-5c16-66a08271bc09@openssl.org>



On 04/04/18 16:38, Jerry L wrote:
> Compiled OpenSSL on AIX 7.1.5.2 using gcc, I used the same Configuration
> options that I have been using for 5 years:
> 
> ??? Configure aix-gcc zlib fips shared
> 
> When running make test, I am getting the following:
> 
> ?test_bad_dtls
> 
> ??? ../util/shlib_wrap.sh .bad_dtls_test
> test_fatalerr
> ???? ../utils/shlib_wrap.sh? ./fatalerrtest ../app/server.pem
> ../apps/server.pem
> SSL_accept() failed -1,?? 1
> 804401144:error:140800FF:SSL routines:ssl3_accept:unknown
> state:s3_srvr.c:869:
> 
> I ran the test on my 1.0.2n build and did not encounter this error.
> 
> Kind of lost here.? Any ideas?

The 1.0.2 tests are very verbose (all that extra output is hidden in
1.1.0 and above). As part of normal tests we do things which are
expected to fail (the test is to check that things we expect to fail
really do fail). If you look through the whole test output you will see
lots of "errors" being generated.

The above is normal test output. Just ignore it. This isn't new for
1.0.2o though - it also exists in 1.0.2n.

Matt


From John.Eichenberger at Honeywell.com  Wed Apr  4 16:06:36 2018
From: John.Eichenberger at Honeywell.com (Eichenberger, John)
Date: Wed, 4 Apr 2018 16:06:36 +0000
Subject: [openssl-users] [External] Re: Correct the check of
 RSA_FLAG_SIGN_VER
In-Reply-To: <20180404.044246.480798974021499228.levitte@openssl.org>
References: <BN6PR07MB3553B5B834436F685450D434F6A50@BN6PR07MB3553.namprd07.prod.outlook.com>
 <20180404.044246.480798974021499228.levitte@openssl.org>
Message-ID: <BN7PR07MB4225009AFD2DCAB8C558F1BAF6A40@BN7PR07MB4225.namprd07.prod.outlook.com>

Honeywell Internal

Your answer #1 below presumes that RSA_new_method() is called AFTER RSA_set_method().  Is that a valid presumption?  How is that documented as a requirement?

When the flag is set in a call to RSA_set_method() after a call to RSA_new(), the flag gets ignored with the current implementation.

-Ike-
  John Eichenberger
Intermec by Honeywell
Principal Engineer:?Sustaining Engineering
425.921.4507

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Richard Levitte
Sent: Tuesday, April 03, 2018 7:43 PM
To: openssl-users at openssl.org
Subject: [External] Re: [openssl-users] Correct the check of RSA_FLAG_SIGN_VER

In message <BN6PR07MB3553B5B834436F685450D434F6A50 at BN6PR07MB3553.namprd07.prod.outlook.com> on Tue, 3 Apr 2018 22:55:06 +0000, "Eichenberger, John" <John.Eichenberger at Honeywell.com> said:

John.Eichenberger> Honeywell Internal
John.Eichenberger>
John.Eichenberger> I think I have an answer for why this commit needed to be reverted:
John.Eichenberger>
John.Eichenberger> Author: Dr. Stephen Henson <steve at openssl.org> John.Eichenberger> Author date: 2 years ago (12/20/2015 10:18:43 AM) John.Eichenberger> Commit date: 2 years ago (12/20/2015 11:27:03 AM) John.Eichenberger> Commit hash: 6656ba7152dfe4bba865e327dd362ea08544aa80
John.Eichenberger> Children: 1c7de36f62
John.Eichenberger> Parent(s): 17592f323a John.Eichenberger> John.Eichenberger> Don't check RSA_FLAG_SIGN_VER.
John.Eichenberger>
John.Eichenberger> Reviewed-by: Richard Levitte <levitte at openssl.org> John.Eichenberger> John.Eichenberger> The change made in that commit was to simply remove John.Eichenberger> the attempt to check for the RSA_FLAG_SIGN_VER flag.
John.Eichenberger> But that's not what is wrong with this code that John.Eichenberger> required changing. The change should be to add John.Eichenberger> "meth" prior to flags:

Well, not quite, actually.  We can easily study the code prior to this change by looking at the 1.0.2 source.

1. in RSA_new_method(), which is used to create new instances of the
   RSA structure, there's this line:

    ret->flags = ret->meth->flags & ~RSA_FLAG_NON_FIPS_ALLOW;

   So that makes the check of rsa->flags valid, no need to go via
   rsa->meth

2. In rsa.h (crypto/rsa/rsa.h in 1.0.2), you'll find this comment in
   the middle of the definition of rsa_meth_st

    /*
     * New sign and verify functions: some libraries don't allow arbitrary
     * data to be signed/verified: this allows them to be used. Note: for
     * this to work the RSA_public_decrypt() and RSA_private_encrypt() should
     * *NOT* be used RSA_sign(), RSA_verify() should be used instead. Note:
     * for backwards compatibility this functionality is only enabled if the
     * RSA_FLAG_SIGN_VER option is set in 'flags'.
     */

   Do note the note on backward compatibility...  you see, there were
   versions of OpenSSL where the fields 'rsa_sign' and 'rsa_verify'
   didn't exist (they appeared in OpenSSL 0.9.5), so for the sake of
   allowing older applications to work with the newer OpenSSL without
   recompilation, we required all new RSA method implementations to
   use that flag to have the 'rsa_sign' and 'rsa_verify' functions
   used.  Without that flag, those functions were assumed not to
   exist, that the RSA method structure was pre-0.9.5.  However, this
   was somewhere in 2000.

   Fast forward to 2015, when we were starting to make certain types
   opaque, and someone noticed this flag still hanging around, and we
   figured that 0.9.5 is long gone, and 1.0.1 was a year away from its
   end of life, and we figured that the reason to have this flag at
   all was a matter of years long past, it was time to simply drop its
   use.  It had grown to become irrelevant a long time ago.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From pratyush.parimal at gmail.com  Wed Apr  4 17:32:18 2018
From: pratyush.parimal at gmail.com (pratyush parimal)
Date: Wed, 4 Apr 2018 13:32:18 -0400
Subject: [openssl-users] Workaround for "SSL_CTX_use_certificate:ca md too
	weak"
Message-ID: <CALvRNOFygRSvRr8Sv3hSTDH-kB3MUk0gsjitXEirO66fKXg1AQ@mail.gmail.com>

Hi everyone,

I'm upgrading a server application from using OpenSSL 1.0.2n to using
OpenSSL 1.1.0g.
I noticed that after the upgrade, some SSL certs get rejected because they
use an MD5 digest, with the error:
"SSL_CTX_use_certificate:ca md too weak"

While I could ask clients to get a better CA certificate, it takes some of
them a long time to do so. I was wondering if there's a way I could
compile/configure the OpenSSL on my server to accept those certificates
after all. Does anyone know?

I found links such as:
https://mta.openssl.org/pipermail/openssl-users/2017-October/006670.html
and
https://www.spinics.net/lists/openssl-users/msg06669.html
and a few others but they don't apply to my case I think.

Also, if the client does find it possible to get re-generated certs, would
it be both the client cert and the CA? Or just one of them?

Thanks in advance!
Best,
Pratyush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180404/32669bdc/attachment.html>

From rsalz at akamai.com  Wed Apr  4 17:51:27 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 4 Apr 2018 17:51:27 +0000
Subject: [openssl-users] Workaround for "SSL_CTX_use_certificate:ca md
 too weak"
In-Reply-To: <CALvRNOFygRSvRr8Sv3hSTDH-kB3MUk0gsjitXEirO66fKXg1AQ@mail.gmail.com>
References: <CALvRNOFygRSvRr8Sv3hSTDH-kB3MUk0gsjitXEirO66fKXg1AQ@mail.gmail.com>
Message-ID: <1F3EE7BE-886A-4E2A-AB26-FBF5FC9A5BC7@akamai.com>

You need to change your server config (however it is done), so that it gets @SECLEVEL=0 into the cipher string.  See the ciphers manpage for description of security levels.

You can also edit openssl source and rebuild/relink, but that shouldn?t be necessary.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180404/99eeee78/attachment.html>

From noreply81 at t-online.de  Wed Apr  4 19:39:56 2018
From: noreply81 at t-online.de (Guido)
Date: Wed, 4 Apr 2018 21:39:56 +0200
Subject: [openssl-users] (no subject)
Message-ID: <1f3oGE-1fhubI0@fwd25.t-online.de>



Gesendet von Mail f?r Windows 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180404/e64b1f96/attachment.html>

From noreply81 at t-online.de  Wed Apr  4 21:31:47 2018
From: noreply81 at t-online.de (Guido)
Date: Wed, 4 Apr 2018 23:31:47 +0200
Subject: [openssl-users] (no subject)
Message-ID: <1f3q0T-11dzou0@fwd17.t-online.de>



Gesendet von Mail f?r Windows 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180404/6ae2464d/attachment.html>

From var.kulkarni at gmail.com  Thu Apr  5 01:14:29 2018
From: var.kulkarni at gmail.com (Varun Kulkarni)
Date: Wed, 4 Apr 2018 18:14:29 -0700
Subject: [openssl-users] DTLS with multiple clients
Message-ID: <CAOtvvcFgfuTYSdDMCDdZZ6ATH1f5SwzQ7acJBqhfyRgJ=9J2uA@mail.gmail.com>

Hi,

I was able to get DTLS work with the latest version of openssl with a
single client and server. However, I was unable to get it to work with
multiple clients. The first client completes the handshake and works well.
But however the function DTLSv1_listen returns 1 immediately even for an
application data packet (after the first client completes the handshake),
where it should ideally return 0 and wait for the next client hello. Since
it hangs on SSL_accept, the next client hello packets won't be answered.


The closest reference I have got is from:
https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5. This doesn't
seem to work for multiple clients.

Any suggestions/references would be helpful in this regard. If this is not
the right mailing list, please point me to the right one.


-- 


Thanks and Regards,
Varun K S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180404/dafc0f9e/attachment.html>

From mytechlist at gmail.com  Thu Apr  5 04:12:43 2018
From: mytechlist at gmail.com (PS)
Date: Wed, 4 Apr 2018 21:12:43 -0700
Subject: [openssl-users] AES-GCM cipher in TLS
Message-ID: <CAAQrBDzLPPKAX2CCyYCAt1J94NJFT_Fo+=dS4dTTCq-6hQODdA@mail.gmail.com>

I am trying to decrypt TLS 1.2 records that is using the
TLS_AES_128_GCM_SHA256 cipher-suite using openssl's EVP API.

Per RFC 5246, decryption needs 4 inputs.
"

   In order to decrypt and verify, the cipher takes as input the key,
   nonce, the "additional_data", and the AEADEncrypted value.  The
   output is either the plaintext or an error indicating that the
   decryption failed.  There is no separate integrity check.  That is:

      TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
                                            AEADEncrypted,
                                            additional_data)

"

But, in the AES-GCM decryption example on openssl wiki at
https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption
shows the decryption also takes as input the* tag *to be verified.

I know that the Authentication tag is the last 16 bytes of the TLS 1.2
record payload. But, my confusion is why the RFC has no mention of the
Authentication tag.

And so, to decrypt the TLS record, should I follow the example on openssl
wiki?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180404/283337c5/attachment-0001.html>

From matt at openssl.org  Thu Apr  5 08:03:39 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 5 Apr 2018 09:03:39 +0100
Subject: [openssl-users] DTLS with multiple clients
In-Reply-To: <CAOtvvcFgfuTYSdDMCDdZZ6ATH1f5SwzQ7acJBqhfyRgJ=9J2uA@mail.gmail.com>
References: <CAOtvvcFgfuTYSdDMCDdZZ6ATH1f5SwzQ7acJBqhfyRgJ=9J2uA@mail.gmail.com>
Message-ID: <8e38b674-cfba-7183-bd51-dd65052a1e70@openssl.org>

Are you able to share a simple reproducer of your problem?

Matt

On 05/04/18 02:14, Varun Kulkarni wrote:
> Hi,
> 
> I was able to get DTLS work with the latest version of openssl?with a
> single client and server. However, I was unable to get it to work with
> multiple clients. The first client completes the handshake and works
> well. But however?the function DTLSv1_listen returns 1 immediately even
> for an application data packet (after the first client completes the
> handshake), where it should ideally return 0 and wait for the next
> client hello. Since it hangs on SSL_accept, the next client hello
> packets won't be answered.??
> 
> 
> The closest reference I have got is from:
> https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5. This
> doesn't seem to work for multiple clients.
> 
> Any suggestions/references would be helpful in this regard. If this is
> not the right mailing list, please point me to the right one.
> 
> 
> -- 
> 
> 
> Thanks and Regards,
> Varun K S
> 
> 

From matt at openssl.org  Thu Apr  5 08:26:07 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 5 Apr 2018 09:26:07 +0100
Subject: [openssl-users] AES-GCM cipher in TLS
In-Reply-To: <CAAQrBDzLPPKAX2CCyYCAt1J94NJFT_Fo+=dS4dTTCq-6hQODdA@mail.gmail.com>
References: <CAAQrBDzLPPKAX2CCyYCAt1J94NJFT_Fo+=dS4dTTCq-6hQODdA@mail.gmail.com>
Message-ID: <38f49fad-2052-98b8-30b4-42d468cb64c6@openssl.org>

On 05/04/18 05:12, PS wrote:
> I am trying to decrypt TLS 1.2 records that is using the
> TLS_AES_128_GCM_SHA256 cipher-suite using openssl's EVP API.
>
> Per RFC 5246, decryption needs 4 inputs.
> "
>
>    In order to decrypt and verify, the cipher takes as input the key,
>    nonce, the "additional_data", and the AEADEncrypted value.  The
>    output is either the plaintext or an error indicating that the
>    decryption failed.  There is no separate integrity check.  That is:
>
>       TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
>                                             AEADEncrypted,
>                                             additional_data)
>
> "
>
> But, in the AES-GCM decryption example on openssl wiki at
>
https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption
> shows the decryption also takes as input the*tag *to be verified.
>
> I know that the Authentication tag is the last 16 bytes of the TLS 1.2
> record payload. But, my confusion is why the RFC has no mention of the
> Authentication tag.

Well you have to look in the right RFC :-). TLSv1.2 is specified in
RFC5246. This contains some high level information about how to use AEAD
ciphersuites in TLSv1.2 (in particular see section 6.2.3.3).

Then there is RFC5288. This should be read in conjunction with RFC5246
and provides information on a set of specific AEAD ciphersuites -
including all of the GCM ones. This provides information on how to
construct the nonce from the explicit and implicit parts. The
ciphersuites make use of the AEAD_AES_128_GCM algorithm as specified in
RFC5116.

RFC5116 has this to say on the authentication tag:

   The AEAD_AES_128_GCM authenticated encryption algorithm works as
   specified in [GCM], using AES-128 as the block cipher, by providing
   the key, nonce, and plaintext, and associated data to that mode of
   operation.  An authentication tag with a length of 16 octets (128
   bits) is used.  The AEAD_AES_128_GCM ciphertext is formed by
   appending the authentication tag provided as an output to the GCM
   encryption operation to the ciphertext that is output by that
   operation.

Matt

From mytechlist at gmail.com  Thu Apr  5 17:35:22 2018
From: mytechlist at gmail.com (PS)
Date: Thu, 5 Apr 2018 10:35:22 -0700
Subject: [openssl-users] AES-GCM cipher in TLS
In-Reply-To: <38f49fad-2052-98b8-30b4-42d468cb64c6@openssl.org>
References: <CAAQrBDzLPPKAX2CCyYCAt1J94NJFT_Fo+=dS4dTTCq-6hQODdA@mail.gmail.com>
 <38f49fad-2052-98b8-30b4-42d468cb64c6@openssl.org>
Message-ID: <CAAQrBDx=RmkTCr6JrwL64utrhazUGk2pKMQMvTkxaGRF-jhidA@mail.gmail.com>

Thanks Matt.

I did read those RFC as well. And here is the confusion. The RFC5116 says
this section 2.1

  There is a *single output:*

      A ciphertext C, which is at least as long as the plaintext, or

      an indication that the requested encryption operation could not be
      performed.

Note the emphasis on "single output". So, encryption output is just a
single output ciphertext C. This C is the ciphertext + tag from what I
understand in a single output. Similarly, section 2.2, does not mention
anything about separating the tag from the Ciphertext and just takes C as
input.

Now assuming that openssl follows this, shouldn't the example at
https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption
just give a single output per the RFC. Instead the example requires Cipher
text and tag to be extracted separately. Conversely, decryption should just
take the ciphertext C (which includes the tag) and output the plaintext.
But again the example requires separating the tag for verification.

In summary, per my understanding of the RFC, the auth tag is seamless and
the application should not have to deal with it separately. Yet, the
openssl example using EVP deals with tag separately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180405/80b604e0/attachment.html>

From var.kulkarni at gmail.com  Thu Apr  5 17:53:47 2018
From: var.kulkarni at gmail.com (Varun Kulkarni)
Date: Thu, 5 Apr 2018 10:53:47 -0700
Subject: [openssl-users] DTLS with multiple clients
In-Reply-To: <8e38b674-cfba-7183-bd51-dd65052a1e70@openssl.org>
References: <CAOtvvcFgfuTYSdDMCDdZZ6ATH1f5SwzQ7acJBqhfyRgJ=9J2uA@mail.gmail.com>
 <8e38b674-cfba-7183-bd51-dd65052a1e70@openssl.org>
Message-ID: <CAOtvvcGZ2BrpY1HDqLp94aV_8g2Ef+sRZ=-SQqZy7y3ZZBq6VQ@mail.gmail.com>

Hi Matt,


I was able to fix the issue with the following changes. The change was to
create new fd (bound to server address) each time DTLSv1_listen() was
called.  Previously, I used the same fd for every DTLSv1_listen call. The
new dgram BIO was created with an old fd. On passing newly created fd to
BIO_new_dgram, the problem seems to be resolved. However, this leads to
another question. Why doesn't DTLS_listen queue up the connections similar
to accept call? Does that mean DTLS can support only one handshake at a
time? Is it recommended to create multiple fds bound to server address and
then spawning a thread (per fd) to listen to DTLS requests.



while(1) {

int fd = socket(AF_INET6, SOCK_DGRAM, 0);bind(fd, &server_addr,
sizeof(struct sockaddr_in6));


BIO *bio = BIO_new_dgram(fd, BIO_NOCLOSE); SSL *ssl = SSL_new(ctx);
SSL_set_bio(ssl, bio, bio); /* Enable cookie exchange */ SSL_set_options(ssl,
SSL_OP_COOKIE_EXCHANGE); /* Wait for incoming connections */ while (!
DTLSv1_listen(ssl, &client_addr)); /* connect to client on different fd and
complete the handshake and process data packets */

}




Thanks,
Varun



On Thu, Apr 5, 2018 at 1:03 AM, Matt Caswell <matt at openssl.org> wrote:

> Are you able to share a simple reproducer of your problem?
>
> Matt
>
> On 05/04/18 02:14, Varun Kulkarni wrote:
> > Hi,
> >
> > I was able to get DTLS work with the latest version of openssl with a
> > single client and server. However, I was unable to get it to work with
> > multiple clients. The first client completes the handshake and works
> > well. But however the function DTLSv1_listen returns 1 immediately even
> > for an application data packet (after the first client completes the
> > handshake), where it should ideally return 0 and wait for the next
> > client hello. Since it hangs on SSL_accept, the next client hello
> > packets won't be answered.
> >
> >
> > The closest reference I have got is from:
> > https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5. This
> > doesn't seem to work for multiple clients.
> >
> > Any suggestions/references would be helpful in this regard. If this is
> > not the right mailing list, please point me to the right one.
> >
> >
> > --
> >
> >
> > Thanks and Regards,
> > Varun K S
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 


Regards,
Varun K S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180405/6841a7ce/attachment.html>

From KHenderson at verisign.com  Thu Apr  5 18:02:17 2018
From: KHenderson at verisign.com (Henderson, Karl)
Date: Thu, 5 Apr 2018 18:02:17 +0000
Subject: [openssl-users] RFC5077 KWK
Message-ID: <C6642DA2-5F34-4CC3-A928-45927C8AAE65@verisign.com>

Is it possible to use 5077 with a key wrapping key in a Needham-Schroeder scenario:


  *   A is a Key Server
  *   C is say a web server
  *   A has a relationship with C and hence A has key KEYac
  *   B wants to talk to C but doesn?t have a relationship with C
  *   B has a relationship with A
  *   B asks A for a key it can use with C
  *   A generates a KEYbc and wraps it with KEYac giving us KEYbcac with key_name KEYac

Is it possible to construct a 5077 style ticket with KEYbcac that can be transparently unwrapped by C so that B can speak with C using KEYbc? By transparently, I mean without modification to the server C.

Thanks,
Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180405/539044c0/attachment-0001.html>

From openssl-users at dukhovni.org  Thu Apr  5 18:19:05 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 5 Apr 2018 14:19:05 -0400
Subject: [openssl-users] RFC5077 KWK
In-Reply-To: <C6642DA2-5F34-4CC3-A928-45927C8AAE65@verisign.com>
References: <C6642DA2-5F34-4CC3-A928-45927C8AAE65@verisign.com>
Message-ID: <C02C3F0C-57D2-4969-A243-72BA0A65FBAE@dukhovni.org>



> On Apr 5, 2018, at 2:02 PM, Henderson, Karl via openssl-users <openssl-users at openssl.org> wrote:
> 
> Is it possible to use 5077 with a key wrapping key in a Needham-Schroeder scenario:
>  
> 	? A is a Key Server
> 	? C is say a web server
> 	? A has a relationship with C and hence A has key KEYac
> 	? B wants to talk to C but doesn?t have a relationship with C
> 	? B has a relationship with A
> 	? B asks A for a key it can use with C
> 	? A generates a KEYbc and wraps it with KEYac giving us KEYbcac with key_name KEYac
>  
> Is it possible to construct a 5077 style ticket with KEYbcac that can be transparently unwrapped by C so that B can speak with C using KEYbc? By transparently, I mean without modification to the server C.

You can use GSSAPI with Kerberos and TLS channel binding.  RFC5077 defines stateless server session resumption, by moving the server state to the client encrypted in the server's key.  The server key should be short-term, and should not be known to any third party (such as A).

The structure of a server session depends on internal implementation details of the server SSL library, and cannot portably be constructed by some other entity.

TLS 1.3 unifies session tickets with (external) PSKs, perhaps you should recast your approach in terms of PSKs rather than session tickets.

-- 
	Viktor.


From KHenderson at verisign.com  Thu Apr  5 18:29:28 2018
From: KHenderson at verisign.com (Henderson, Karl)
Date: Thu, 5 Apr 2018 18:29:28 +0000
Subject: [openssl-users] RFC5077 KWK
In-Reply-To: <C02C3F0C-57D2-4969-A243-72BA0A65FBAE@dukhovni.org>
References: <C6642DA2-5F34-4CC3-A928-45927C8AAE65@verisign.com>
 <C02C3F0C-57D2-4969-A243-72BA0A65FBAE@dukhovni.org>
Message-ID: <1033399D-03D4-42C6-ADDA-F8ABF7D8721F@verisign.com>

Thanks,

> TLS 1.3 unifies session tickets with (external) PSKs, perhaps you should recast your approach in terms of PSKs rather than session tickets.

Is there a good implementation example of this?

?On 4/5/18, 2:19 PM, "openssl-users on behalf of Viktor Dukhovni" <openssl-users-bounces at openssl.org on behalf of openssl-users at dukhovni.org> wrote:

    
    
    > On Apr 5, 2018, at 2:02 PM, Henderson, Karl via openssl-users <openssl-users at openssl.org> wrote:
    > 
    > Is it possible to use 5077 with a key wrapping key in a Needham-Schroeder scenario:
    >  
    > 	? A is a Key Server
    > 	? C is say a web server
    > 	? A has a relationship with C and hence A has key KEYac
    > 	? B wants to talk to C but doesn?t have a relationship with C
    > 	? B has a relationship with A
    > 	? B asks A for a key it can use with C
    > 	? A generates a KEYbc and wraps it with KEYac giving us KEYbcac with key_name KEYac
    >  
    > Is it possible to construct a 5077 style ticket with KEYbcac that can be transparently unwrapped by C so that B can speak with C using KEYbc? By transparently, I mean without modification to the server C.
    
    You can use GSSAPI with Kerberos and TLS channel binding.  RFC5077 defines stateless server session resumption, by moving the server state to the client encrypted in the server's key.  The server key should be short-term, and should not be known to any third party (such as A).
    
    The structure of a server session depends on internal implementation details of the server SSL library, and cannot portably be constructed by some other entity.
    
    TLS 1.3 unifies session tickets with (external) PSKs, perhaps you should recast your approach in terms of PSKs rather than session tickets.
    
    -- 
    	Viktor.
    
    -- 
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
    


From openssl-users at dukhovni.org  Thu Apr  5 18:35:01 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 5 Apr 2018 14:35:01 -0400
Subject: [openssl-users] RFC5077 KWK
In-Reply-To: <1033399D-03D4-42C6-ADDA-F8ABF7D8721F@verisign.com>
References: <C6642DA2-5F34-4CC3-A928-45927C8AAE65@verisign.com>
 <C02C3F0C-57D2-4969-A243-72BA0A65FBAE@dukhovni.org>
 <1033399D-03D4-42C6-ADDA-F8ABF7D8721F@verisign.com>
Message-ID: <7C074849-A5F1-41AB-8D43-9C5E5391FA5B@dukhovni.org>



> On Apr 5, 2018, at 2:29 PM, Henderson, Karl via openssl-users <openssl-users at openssl.org> wrote:
> 
>> TLS 1.3 unifies session tickets with (external) PSKs, perhaps you should recast your approach in terms of PSKs rather than session tickets.
> 
> Is there a good implementation example of this?

I think you'd be trailblazing there.  Good luck.

-- 
	Viktor.


From KHenderson at verisign.com  Thu Apr  5 18:35:56 2018
From: KHenderson at verisign.com (Henderson, Karl)
Date: Thu, 5 Apr 2018 18:35:56 +0000
Subject: [openssl-users] RFC5077 KWK
In-Reply-To: <7C074849-A5F1-41AB-8D43-9C5E5391FA5B@dukhovni.org>
References: <C6642DA2-5F34-4CC3-A928-45927C8AAE65@verisign.com>
 <C02C3F0C-57D2-4969-A243-72BA0A65FBAE@dukhovni.org>
 <1033399D-03D4-42C6-ADDA-F8ABF7D8721F@verisign.com>
 <7C074849-A5F1-41AB-8D43-9C5E5391FA5B@dukhovni.org>
Message-ID: <051B10A4-1A3F-477F-88C4-5736944BC388@verisign.com>

Thanks

?On 4/5/18, 2:35 PM, "openssl-users on behalf of Viktor Dukhovni" <openssl-users-bounces at openssl.org on behalf of openssl-users at dukhovni.org> wrote:

    
    
    > On Apr 5, 2018, at 2:29 PM, Henderson, Karl via openssl-users <openssl-users at openssl.org> wrote:
    > 
    >> TLS 1.3 unifies session tickets with (external) PSKs, perhaps you should recast your approach in terms of PSKs rather than session tickets.
    > 
    > Is there a good implementation example of this?
    
    I think you'd be trailblazing there.  Good luck.
    
    -- 
    	Viktor.
    
    -- 
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
    


From matt at openssl.org  Thu Apr  5 21:57:19 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 5 Apr 2018 22:57:19 +0100
Subject: [openssl-users] AES-GCM cipher in TLS
In-Reply-To: <CAAQrBDx=RmkTCr6JrwL64utrhazUGk2pKMQMvTkxaGRF-jhidA@mail.gmail.com>
References: <CAAQrBDzLPPKAX2CCyYCAt1J94NJFT_Fo+=dS4dTTCq-6hQODdA@mail.gmail.com>
 <38f49fad-2052-98b8-30b4-42d468cb64c6@openssl.org>
 <CAAQrBDx=RmkTCr6JrwL64utrhazUGk2pKMQMvTkxaGRF-jhidA@mail.gmail.com>
Message-ID: <a756fa80-b2aa-08c1-426c-b0abf7252ee6@openssl.org>



On 05/04/18 18:35, PS wrote:
> Thanks Matt.
> 
> I did read those RFC as well. And here is the confusion. The RFC5116
> says this section 2.1
> 
>   There is a *single output:*
> 
>       A ciphertext C, which is at least as long as the plaintext, or
> 
>       an indication that the requested encryption operation could not be
>       performed.
> 
> Note the emphasis on "single output". So, encryption output is just a
> single output ciphertext C. This C is the ciphertext + tag from what I
> understand in a single output. Similarly, section 2.2, does not mention
> anything about separating the tag from the Ciphertext and just takes C
> as input.
> 
> Now assuming that openssl follows this, shouldn't the example at
> https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption
> just give a single output per the RFC. Instead the example requires
> Cipher text and tag to be extracted separately. Conversely, decryption
> should just take the ciphertext C (which includes the tag) and output
> the plaintext. But again the example requires separating the tag for
> verification.
> 
> In summary, per my understanding of the RFC, the auth tag is seamless
> and the application should not have to deal with it separately. Yet, the
> openssl example using EVP deals with tag separately.

Right - I understand where your confusion is. The EVP interface is *not*
an RFC5116 API. RFC5116 is itself built on top of another standard -
SP800-38D. The EVP API gives you an interface to GCM as defined in that
standard. RFC5116 wraps that standard with some additional requirements
such as the fact that tag is 16 octets in length and appended to the end
of the ciphertext. OpenSSL implements RFC5116 only in as much as it is
required to implement the TLS ciphersuites in libssl. The EVP interface
is just a building block provided by libcrypto to create those ciphersuites.

Matt

From matt at openssl.org  Thu Apr  5 22:06:35 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 5 Apr 2018 23:06:35 +0100
Subject: [openssl-users] DTLS with multiple clients
In-Reply-To: <CAOtvvcGZ2BrpY1HDqLp94aV_8g2Ef+sRZ=-SQqZy7y3ZZBq6VQ@mail.gmail.com>
References: <CAOtvvcFgfuTYSdDMCDdZZ6ATH1f5SwzQ7acJBqhfyRgJ=9J2uA@mail.gmail.com>
 <8e38b674-cfba-7183-bd51-dd65052a1e70@openssl.org>
 <CAOtvvcGZ2BrpY1HDqLp94aV_8g2Ef+sRZ=-SQqZy7y3ZZBq6VQ@mail.gmail.com>
Message-ID: <28688c3e-7126-6878-0373-78c00b78b3c9@openssl.org>



On 05/04/18 18:53, Varun Kulkarni wrote:
> Hi Matt,
> 
> 
> I was able to fix the issue with the following changes. The change was
> to create new fd?(bound to server address) each time DTLSv1_listen() was
> called.

There should be no need to do that. Instead, when DTLSv1_listen returns
successfully, you should create a new fd for the *client* (connected to
their address as returned from DTLSv1_listen()), and then update the SSL
object for the client to use that fd. You can reuse the old fd for the
next DTLSv1_listen call. You will need a new SSL object for the next
DTLSv1_listen() call though.

Matt

>? Previously, I used the same fd for every DTLSv1_listen call.
> The new dgram?BIO was created with an old?fd. On passing newly created
> fd?to BIO_new_dgram, the problem seems to be resolved. However, this
> leads to another question. Why doesn't?DTLS_listen queue up the
> connections similar to accept call? Does that mean DTLS can support only
> one handshake at a time? Is it recommended to create multiple fds?bound
> to server address and then spawning a thread (per fd) to listen to DTLS
> requests.
> 
> ? ? ?
> 
> while(1) {
> 
> int fd = socket(AF_INET6, SOCK_DGRAM, 0);
> bind(fd, &server_addr, sizeof(struct sockaddr_in6));
> 
> 
> 
>   BIO *bio = BIO_new_dgram(fd, BIO_NOCLOSE);
>   SSL *ssl = SSL_new(ctx);
>   SSL_set_bio(ssl, bio, bio);
> 
>   /* Enable cookie exchange */
>   SSL_set_options(ssl, SSL_OP_COOKIE_EXCHANGE);
> 
>   /* Wait for incoming connections */
>   while (!DTLSv1_listen(ssl, &client_addr));
> 
>   /* connect to client on different fd and complete the handshake and
> process data packets */
> 
> }
> 
> 
> 
> 
> Thanks,
> Varun
> 
> 
> 
> On Thu, Apr 5, 2018 at 1:03 AM, Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
>     Are you able to share a simple reproducer of your problem?
> 
>     Matt
> 
>     On 05/04/18 02:14, Varun Kulkarni wrote:
>     > Hi,
>     >
>     > I was able to get DTLS work with the latest version of openssl?with a
>     > single client and server. However, I was unable to get it to work with
>     > multiple clients. The first client completes the handshake and works
>     > well. But however?the function DTLSv1_listen returns 1 immediately
>     even
>     > for an application data packet (after the first client completes the
>     > handshake), where it should ideally return 0 and wait for the next
>     > client hello. Since it hangs on SSL_accept, the next client hello
>     > packets won't be answered.??
>     >
>     >
>     > The closest reference I have got is from:
>     > https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5
>     <https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5>. This
>     > doesn't seem to work for multiple clients.
>     >
>     > Any suggestions/references would be helpful in this regard. If this is
>     > not the right mailing list, please point me to the right one.
>     >
>     >
>     > --
>     >
>     >
>     > Thanks and Regards,
>     > Varun K S
>     >
>     >
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
> 
> 
> 
> 
> -- 
> 
> 
> Regards,
> Varun K S
> 
> 

From var.kulkarni at gmail.com  Thu Apr  5 22:37:01 2018
From: var.kulkarni at gmail.com (Varun Kulkarni)
Date: Thu, 5 Apr 2018 15:37:01 -0700
Subject: [openssl-users] DTLS with multiple clients
In-Reply-To: <28688c3e-7126-6878-0373-78c00b78b3c9@openssl.org>
References: <CAOtvvcFgfuTYSdDMCDdZZ6ATH1f5SwzQ7acJBqhfyRgJ=9J2uA@mail.gmail.com>
 <8e38b674-cfba-7183-bd51-dd65052a1e70@openssl.org>
 <CAOtvvcGZ2BrpY1HDqLp94aV_8g2Ef+sRZ=-SQqZy7y3ZZBq6VQ@mail.gmail.com>
 <28688c3e-7126-6878-0373-78c00b78b3c9@openssl.org>
Message-ID: <CAOtvvcHKd_XMt+8usTsd=VHhZhhRvCNK4RwX=aNozcyYJ-h3uQ@mail.gmail.com>

On Thu, Apr 5, 2018 at 3:06 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 05/04/18 18:53, Varun Kulkarni wrote:
> > Hi Matt,
> >
> >
> > I was able to fix the issue with the following changes. The change was
> > to create new fd (bound to server address) each time DTLSv1_listen() was
> > called.
>
> There should be no need to do that. Instead, when DTLSv1_listen returns
> successfully, you should create a new fd for the *client* (connected to
> their address as returned from DTLSv1_listen()), and then update the SSL
> object for the client to use that fd. You can reuse the old fd for the
> next DTLSv1_listen call. You will need a new SSL object for the next
> DTLSv1_listen() call though.
>
> Matt
>


Thanks for the reply Matt. Previosuly , I did the exact thing you
mentioned. But in that case , the DTLSV1_listen returns succesfully (> 0)
immediately on reception of
app packet and hangs on SSL_accept.

Here is tshark trace of the same:

    1 0.000000000    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
    2 0.000136330    127.0.0.1 ? 127.0.0.1    DTLSv1.0 90 Hello Verify
Request
    3 0.000258998    127.0.0.1 ? 127.0.0.1    DTLSv1.0 264 Client Hello
    4 0.999217798    127.0.0.1 ? 127.0.0.1    DTLSv1.0 264 Client Hello
    5 1.001095034    127.0.0.1 ? 127.0.0.1    DTLSv1.0 1482 Server Hello,
Certificate, Server Key Exchange, Certificate Request, Server Hello Done
    6 1.003771485    127.0.0.1 ? 127.0.0.1    DTLSv1.0 1457 Certificate,
Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted
Handshake Message
    7 1.004282757    127.0.0.1 ? 127.0.0.1    DTLSv1.0 1252 New Session
Ticket, Change Cipher Spec, Encrypted Handshake Message
    8 4.313854533    127.0.0.1 ? 127.0.0.1    DTLSv1.0 103 Application Data
    9 4.314110117    127.0.0.1 ? 127.0.0.1    DTLSv1.0 295 Application
Data
 *  10 31.662557986    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello*
   11 32.662344551    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
   12 34.665481449    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
   13 38.662321433    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
   14 46.662998247    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
   15 62.662816876    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello

The trace starting from 10 is from the second client and it hangs because
DTLSv1_listen has already returned and is struck on SSL_accept.

Can you clarify that at any moment of time, dtls can process only one
handshake at a time.

-Varun



>
> >  Previously, I used the same fd for every DTLSv1_listen call.
> > The new dgram BIO was created with an old fd. On passing newly created
> > fd to BIO_new_dgram, the problem seems to be resolved. However, this
> > leads to another question. Why doesn't DTLS_listen queue up the
> > connections similar to accept call? Does that mean DTLS can support only
> > one handshake at a time? Is it recommended to create multiple fds bound
> > to server address and then spawning a thread (per fd) to listen to DTLS
> > requests.
> >
> >
> >
> > while(1) {
> >
> > int fd = socket(AF_INET6, SOCK_DGRAM, 0);
> > bind(fd, &server_addr, sizeof(struct sockaddr_in6));
> >
> >
> >
> >   BIO *bio = BIO_new_dgram(fd, BIO_NOCLOSE);
> >   SSL *ssl = SSL_new(ctx);
> >   SSL_set_bio(ssl, bio, bio);
> >
> >   /* Enable cookie exchange */
> >   SSL_set_options(ssl, SSL_OP_COOKIE_EXCHANGE);
> >
> >   /* Wait for incoming connections */
> >   while (!DTLSv1_listen(ssl, &client_addr));
> >
> >   /* connect to client on different fd and complete the handshake and
> > process data packets */
> >
> > }
> >
> >
> >
> >
> > Thanks,
> > Varun
> >
> >
> >
> > On Thu, Apr 5, 2018 at 1:03 AM, Matt Caswell <matt at openssl.org
> > <mailto:matt at openssl.org>> wrote:
> >
> >     Are you able to share a simple reproducer of your problem?
> >
> >     Matt
> >
> >     On 05/04/18 02:14, Varun Kulkarni wrote:
> >     > Hi,
> >     >
> >     > I was able to get DTLS work with the latest version of
> openssl with a
> >     > single client and server. However, I was unable to get it to work
> with
> >     > multiple clients. The first client completes the handshake and
> works
> >     > well. But however the function DTLSv1_listen returns 1 immediately
> >     even
> >     > for an application data packet (after the first client completes
> the
> >     > handshake), where it should ideally return 0 and wait for the next
> >     > client hello. Since it hangs on SSL_accept, the next client hello
> >     > packets won't be answered.
> >     >
> >     >
> >     > The closest reference I have got is from:
> >     > https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5
> >     <https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5>.
> This
> >     > doesn't seem to work for multiple clients.
> >     >
> >     > Any suggestions/references would be helpful in this regard. If
> this is
> >     > not the right mailing list, please point me to the right one.
> >     >
> >     >
> >     > --
> >     >
> >     >
> >     > Thanks and Regards,
> >     > Varun K S
> >     >
> >     >
> >     --
> >     openssl-users mailing list
> >     To unsubscribe:
> >     https://mta.openssl.org/mailman/listinfo/openssl-users
> >     <https://mta.openssl.org/mailman/listinfo/openssl-users>
> >
> >
> >
> >
> > --
> >
> >
> > Regards,
> > Varun K S
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 


Regards,
Varun K S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180405/b281ae4e/attachment.html>

From matt at openssl.org  Thu Apr  5 23:03:22 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 6 Apr 2018 00:03:22 +0100
Subject: [openssl-users] DTLS with multiple clients
In-Reply-To: <CAOtvvcHKd_XMt+8usTsd=VHhZhhRvCNK4RwX=aNozcyYJ-h3uQ@mail.gmail.com>
References: <CAOtvvcFgfuTYSdDMCDdZZ6ATH1f5SwzQ7acJBqhfyRgJ=9J2uA@mail.gmail.com>
 <8e38b674-cfba-7183-bd51-dd65052a1e70@openssl.org>
 <CAOtvvcGZ2BrpY1HDqLp94aV_8g2Ef+sRZ=-SQqZy7y3ZZBq6VQ@mail.gmail.com>
 <28688c3e-7126-6878-0373-78c00b78b3c9@openssl.org>
 <CAOtvvcHKd_XMt+8usTsd=VHhZhhRvCNK4RwX=aNozcyYJ-h3uQ@mail.gmail.com>
Message-ID: <f9f5ee14-c946-b76c-c08d-b8d7b73cbba7@openssl.org>



On 05/04/18 23:37, Varun Kulkarni wrote:

> 
> Thanks for the reply Matt. Previosuly , I did the exact thing you
> mentioned. But in that case , the DTLSV1_listen returns succesfully (>
> 0) immediately on reception of
> app packet and hangs on SSL_accept.
> 
> Here is tshark trace of the same:
> 
> ? ? 1 0.000000000? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello
> ? ? 2 0.000136330? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 90 Hello Verify
> Request
> ? ? 3 0.000258998? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 264 Client Hello
> ? ? 4 0.999217798? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 264 Client Hello
> ? ? 5 1.001095034? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 1482 Server
> Hello, Certificate, Server Key Exchange, Certificate Request, Server
> Hello Done
> ? ? 6 1.003771485? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 1457 Certificate,
> Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted
> Handshake Message
> ? ? 7 1.004282757? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 1252 New Session
> Ticket, Change Cipher Spec, Encrypted Handshake Message
> ? ? 8 4.313854533? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 103 Application Data
> ? ? 9 4.314110117? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 295 Application
> Data? ?
> ?*?10 31.662557986? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello*
> ? ?11 32.662344551? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello
> ? ?12 34.665481449? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello
> ? ?13 38.662321433? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello
> ? ?14 46.662998247? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello
> ? ?15 62.662816876? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello
> 
> The trace starting from 10 is from the second client and it hangs
> because DTLSv1_listen has already returned and is struck on SSL_accept.
> 
> Can you clarify that at any moment of time, dtls can process only one
> handshake at a time.?

For any single thread that is true. It is self evident that in a single
thread you can only do one thing at a time. But plenty of applications
still manage to handle multiple simultaneous clients! There are two
general ways that applications solve this problem.

1) Have one thread for DTLSv1_listen. When a client connects offload the
SSL_accept call to some other thread. In the first thread you can loop
around and call DTLSv1_listen again while, at the same time, the second
thread can process the handshake with the connected client.

or

2) Interleave processing of different clients and DTLSv1_listen within
the same thread. Usually on some event driven process (e.g. select,
poll, epoll, libevent etc). So in this case you set the underlying fd to
be non-blocking and then handle the
SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE errors than you get back from
OpenSSL (see man page for SSL_get_error).

Matt

From var.kulkarni at gmail.com  Thu Apr  5 23:17:01 2018
From: var.kulkarni at gmail.com (Varun Kulkarni)
Date: Thu, 5 Apr 2018 16:17:01 -0700
Subject: [openssl-users] DTLS with multiple clients
In-Reply-To: <f9f5ee14-c946-b76c-c08d-b8d7b73cbba7@openssl.org>
References: <CAOtvvcFgfuTYSdDMCDdZZ6ATH1f5SwzQ7acJBqhfyRgJ=9J2uA@mail.gmail.com>
 <8e38b674-cfba-7183-bd51-dd65052a1e70@openssl.org>
 <CAOtvvcGZ2BrpY1HDqLp94aV_8g2Ef+sRZ=-SQqZy7y3ZZBq6VQ@mail.gmail.com>
 <28688c3e-7126-6878-0373-78c00b78b3c9@openssl.org>
 <CAOtvvcHKd_XMt+8usTsd=VHhZhhRvCNK4RwX=aNozcyYJ-h3uQ@mail.gmail.com>
 <f9f5ee14-c946-b76c-c08d-b8d7b73cbba7@openssl.org>
Message-ID: <CAOtvvcECQ7vATFX8Ct=q8WcsfCEyEsqa5emTCHF73dKVfYTveA@mail.gmail.com>

On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 05/04/18 23:37, Varun Kulkarni wrote:
>
> >
> > Thanks for the reply Matt. Previosuly , I did the exact thing you
> > mentioned. But in that case , the DTLSV1_listen returns succesfully (>
> > 0) immediately on reception of
> > app packet and hangs on SSL_accept.
> >
> > Here is tshark trace of the same:
> >
> >     1 0.000000000    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
> >     2 0.000136330    127.0.0.1 ? 127.0.0.1    DTLSv1.0 90 Hello Verify
> > Request
> >     3 0.000258998    127.0.0.1 ? 127.0.0.1    DTLSv1.0 264 Client Hello
> >     4 0.999217798    127.0.0.1 ? 127.0.0.1    DTLSv1.0 264 Client Hello
> >     5 1.001095034    127.0.0.1 ? 127.0.0.1    DTLSv1.0 1482 Server
> > Hello, Certificate, Server Key Exchange, Certificate Request, Server
> > Hello Done
> >     6 1.003771485    127.0.0.1 ? 127.0.0.1    DTLSv1.0 1457 Certificate,
> > Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted
> > Handshake Message
> >     7 1.004282757    127.0.0.1 ? 127.0.0.1    DTLSv1.0 1252 New Session
> > Ticket, Change Cipher Spec, Encrypted Handshake Message
> >     8 4.313854533    127.0.0.1 ? 127.0.0.1    DTLSv1.0 103 Application
> Data
> >     9 4.314110117    127.0.0.1 ? 127.0.0.1    DTLSv1.0 295 Application
> > Data
> >  * 10 31.662557986    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello*
> >    11 32.662344551    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
> >    12 34.665481449    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
> >    13 38.662321433    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
> >    14 46.662998247    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
> >    15 62.662816876    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
> >
> > The trace starting from 10 is from the second client and it hangs
> > because DTLSv1_listen has already returned and is struck on SSL_accept.
> >
> > Can you clarify that at any moment of time, dtls can process only one
> > handshake at a time.
>
> For any single thread that is true. It is self evident that in a single
> thread you can only do one thing at a time. But plenty of applications
> still manage to handle multiple simultaneous clients! There are two
> general ways that applications solve this problem.
>
> 1) Have one thread for DTLSv1_listen. When a client connects offload the
> SSL_accept call to some other thread. In the first thread you can loop
> around and call DTLSv1_listen again while, at the same time, the second
> thread can process the handshake with the connected client.
>

>> This is what I tried to do. But it appears that DTLSV1_listen() fails to
send the Hello verify request for the second client.

>
> or
>
> 2) Interleave processing of different clients and DTLSv1_listen within
> the same thread. Usually on some event driven process (e.g. select,
> poll, epoll, libevent etc). So in this case you set the underlying fd to
> be non-blocking and then handle the
> SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE errors than you get back from
> OpenSSL (see man page for SSL_get_error).
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 


Regards,
Varun K S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180405/c5194a26/attachment-0001.html>

From var.kulkarni at gmail.com  Thu Apr  5 23:19:00 2018
From: var.kulkarni at gmail.com (Varun Kulkarni)
Date: Thu, 5 Apr 2018 16:19:00 -0700
Subject: [openssl-users] DTLS with multiple clients
In-Reply-To: <f9f5ee14-c946-b76c-c08d-b8d7b73cbba7@openssl.org>
References: <CAOtvvcFgfuTYSdDMCDdZZ6ATH1f5SwzQ7acJBqhfyRgJ=9J2uA@mail.gmail.com>
 <8e38b674-cfba-7183-bd51-dd65052a1e70@openssl.org>
 <CAOtvvcGZ2BrpY1HDqLp94aV_8g2Ef+sRZ=-SQqZy7y3ZZBq6VQ@mail.gmail.com>
 <28688c3e-7126-6878-0373-78c00b78b3c9@openssl.org>
 <CAOtvvcHKd_XMt+8usTsd=VHhZhhRvCNK4RwX=aNozcyYJ-h3uQ@mail.gmail.com>
 <f9f5ee14-c946-b76c-c08d-b8d7b73cbba7@openssl.org>
Message-ID: <CAOtvvcGTbd07iyLBgocnBspzsBgdqVHXC_mXkY+fpCNgvocxUg@mail.gmail.com>

On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 05/04/18 23:37, Varun Kulkarni wrote:
>
> >
> > Thanks for the reply Matt. Previosuly , I did the exact thing you
> > mentioned. But in that case , the DTLSV1_listen returns succesfully (>
> > 0) immediately on reception of
> > app packet and hangs on SSL_accept.
> >
> > Here is tshark trace of the same:
> >
> >     1 0.000000000    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
> >     2 0.000136330    127.0.0.1 ? 127.0.0.1    DTLSv1.0 90 Hello Verify
> > Request
> >     3 0.000258998    127.0.0.1 ? 127.0.0.1    DTLSv1.0 264 Client Hello
> >     4 0.999217798    127.0.0.1 ? 127.0.0.1    DTLSv1.0 264 Client Hello
> >     5 1.001095034    127.0.0.1 ? 127.0.0.1    DTLSv1.0 1482 Server
> > Hello, Certificate, Server Key Exchange, Certificate Request, Server
> > Hello Done
> >     6 1.003771485    127.0.0.1 ? 127.0.0.1    DTLSv1.0 1457 Certificate,
> > Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted
> > Handshake Message
> >     7 1.004282757    127.0.0.1 ? 127.0.0.1    DTLSv1.0 1252 New Session
> > Ticket, Change Cipher Spec, Encrypted Handshake Message
> >     8 4.313854533    127.0.0.1 ? 127.0.0.1    DTLSv1.0 103 Application
> Data
> >     9 4.314110117    127.0.0.1 ? 127.0.0.1    DTLSv1.0 295 Application
> > Data
> >  * 10 31.662557986    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello*
> >    11 32.662344551    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
> >    12 34.665481449    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
> >    13 38.662321433    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
> >    14 46.662998247    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
> >    15 62.662816876    127.0.0.1 ? 127.0.0.1    SSL 244 Client Hello
> >
> > The trace starting from 10 is from the second client and it hangs
> > because DTLSv1_listen has already returned and is struck on SSL_accept.
> >
> > Can you clarify that at any moment of time, dtls can process only one
> > handshake at a time.
>
> For any single thread that is true. It is self evident that in a single
> thread you can only do one thing at a time. But plenty of applications
> still manage to handle multiple simultaneous clients! There are two
> general ways that applications solve this problem.
>
> 1) Have one thread for DTLSv1_listen. When a client connects offload the
> SSL_accept call to some other thread. In the first thread you can loop
> around and call DTLSv1_listen again while, at the same time, the second
> thread can process the handshake with the connected client.
>
>
 This is what I tried to do. But it appears that DTLSV1_listen() fails to
send
 the Hello verify request for the second client (Refer trace above). But If
I recreate the fd
 every time in the thread, it works as expected.

or
>
> 2) Interleave processing of different clients and DTLSv1_listen within
> the same thread. Usually on some event driven process (e.g. select,
> poll, epoll, libevent etc). So in this case you set the underlying fd to
> be non-blocking and then handle the
> SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE errors than you get back from
> OpenSSL (see man page for SSL_get_error).
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 


Regards,
Varun K S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180405/d1940378/attachment.html>

From matt at openssl.org  Thu Apr  5 23:30:06 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 6 Apr 2018 00:30:06 +0100
Subject: [openssl-users] DTLS with multiple clients
In-Reply-To: <CAOtvvcGTbd07iyLBgocnBspzsBgdqVHXC_mXkY+fpCNgvocxUg@mail.gmail.com>
References: <CAOtvvcFgfuTYSdDMCDdZZ6ATH1f5SwzQ7acJBqhfyRgJ=9J2uA@mail.gmail.com>
 <8e38b674-cfba-7183-bd51-dd65052a1e70@openssl.org>
 <CAOtvvcGZ2BrpY1HDqLp94aV_8g2Ef+sRZ=-SQqZy7y3ZZBq6VQ@mail.gmail.com>
 <28688c3e-7126-6878-0373-78c00b78b3c9@openssl.org>
 <CAOtvvcHKd_XMt+8usTsd=VHhZhhRvCNK4RwX=aNozcyYJ-h3uQ@mail.gmail.com>
 <f9f5ee14-c946-b76c-c08d-b8d7b73cbba7@openssl.org>
 <CAOtvvcGTbd07iyLBgocnBspzsBgdqVHXC_mXkY+fpCNgvocxUg@mail.gmail.com>
Message-ID: <113488a0-0278-8ff9-9a21-710cea1ff94a@openssl.org>



On 06/04/18 00:19, Varun Kulkarni wrote:
> 
> 
> On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 05/04/18 23:37, Varun Kulkarni wrote:
> 
>     >
>     > Thanks for the reply Matt. Previosuly , I did the exact thing you
>     > mentioned. But in that case , the DTLSV1_listen returns succesfully (>
>     > 0) immediately on reception of
>     > app packet and hangs on SSL_accept.
>     >
>     > Here is tshark trace of the same:
>     >
>     > ? ? 1 0.000000000? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello
>     > ? ? 2 0.000136330? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 90 Hello Verify
>     > Request
>     > ? ? 3 0.000258998? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 264 Client Hello
>     > ? ? 4 0.999217798? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 264 Client Hello
>     > ? ? 5 1.001095034? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 1482 Server
>     > Hello, Certificate, Server Key Exchange, Certificate Request, Server
>     > Hello Done
>     > ? ? 6 1.003771485? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 1457 Certificate,
>     > Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted
>     > Handshake Message
>     > ? ? 7 1.004282757? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 1252 New Session
>     > Ticket, Change Cipher Spec, Encrypted Handshake Message
>     > ? ? 8 4.313854533? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 103 Application Data
>     > ? ? 9 4.314110117? ? 127.0.0.1 ? 127.0.0.1? ? DTLSv1.0 295 Application
>     > Data? ?
>     > ?*?10 31.662557986? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello*
>     > ? ?11 32.662344551? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello
>     > ? ?12 34.665481449? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello
>     > ? ?13 38.662321433? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello
>     > ? ?14 46.662998247? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello
>     > ? ?15 62.662816876? ? 127.0.0.1 ? 127.0.0.1? ? SSL 244 Client Hello
>     >
>     > The trace starting from 10 is from the second client and it hangs
>     > because DTLSv1_listen has already returned and is struck on SSL_accept.
>     >
>     > Can you clarify that at any moment of time, dtls can process only one
>     > handshake at a time.?
> 
>     For any single thread that is true. It is self evident that in a single
>     thread you can only do one thing at a time. But plenty of applications
>     still manage to handle multiple simultaneous clients! There are two
>     general ways that applications solve this problem.
> 
>     1) Have one thread for DTLSv1_listen. When a client connects offload the
>     SSL_accept call to some other thread. In the first thread you can loop
>     around and call DTLSv1_listen again while, at the same time, the second
>     thread can process the handshake with the connected client.
> 
> 
> ?This is what I tried to do. But it appears that DTLSV1_listen() fails
> to send
> ?the Hello verify request for the second client (Refer trace above). But
> If I recreate the fd
> ?every time in the thread, it works as expected.

This code is quite old now and some things have moved on a bit in terms
of the OpenSSL API, but take a look at the sample code here:

https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c

This might give you some hints about how to tackle the problem.

Matt



> 
>     or
> 
>     2) Interleave processing of different clients and DTLSv1_listen within
>     the same thread. Usually on some event driven process (e.g. select,
>     poll, epoll, libevent etc). So in this case you set the underlying fd to
>     be non-blocking and then handle the
>     SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE errors than you get back from
>     OpenSSL (see man page for SSL_get_error).
> 
>     Matt
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
> 
> 
> 
> 
> -- 
> 
> 
> Regards,
> Varun K S
> 
> 

From John.Eichenberger at Honeywell.com  Fri Apr  6 16:41:27 2018
From: John.Eichenberger at Honeywell.com (Eichenberger, John)
Date: Fri, 6 Apr 2018 16:41:27 +0000
Subject: [openssl-users] [External] Re: Correct the check of
 RSA_FLAG_SIGN_VER
In-Reply-To: <BN7PR07MB4225009AFD2DCAB8C558F1BAF6A40@BN7PR07MB4225.namprd07.prod.outlook.com>
References: <BN6PR07MB3553B5B834436F685450D434F6A50@BN6PR07MB3553.namprd07.prod.outlook.com>
 <20180404.044246.480798974021499228.levitte@openssl.org>
 <BN7PR07MB4225009AFD2DCAB8C558F1BAF6A40@BN7PR07MB4225.namprd07.prod.outlook.com>
Message-ID: <BN7PR07MB42251DAB93E28A05F5FAABA4F6BA0@BN7PR07MB4225.namprd07.prod.outlook.com>

Knowing now that RSA_new_method() copies the RSA_METHOD flags field to the RSA flags field I modified my instance of wpa_supplicant such that it works even without changing OpenSSL.
However, I still say that this is a bug with OpenSSL.  Let me tell you the short story that leads me to that conclusion.

wpa_supplicant has a bit of code that
1.  Allocates and defines a RSA_METHOD structure.
2. calls RSA_new();
3. calls RSA_set_method().

In that code the rsa_sign and rsa_verify members of the RSA_METHOD structure are not defined, thus making it compatible with the really old versions of OpenSSL.
But I need to change that and use the rsa_sign method, so I set the RSA_FLAG_SIGN_VER bit of the RSA_METHOD structure to indicate that I need to use that.
But my rsa_sign method was never called.

My "fix" is to set that same bit in the RSA flags field before calling RSA_set_method.
	rsa->flags |= RSA_FLAG_SIGN_VER;

But shouldn't OpenSSL work without me having to do that?
Perhaps RSA_set_method() should also copy the flags field to match what RSA_new_method does?

Either that, or the meth->flags field should be tested.
Which is it?

-Ike-
  John Eichenberger
Intermec by Honeywell
Principal Engineer:?Sustaining Engineering
425.921.4507

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Eichenberger, John
Sent: Wednesday, April 04, 2018 9:07 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [External] Re: Correct the check of RSA_FLAG_SIGN_VER

Honeywell Internal

Your answer #1 below presumes that RSA_new_method() is called AFTER RSA_set_method().  Is that a valid presumption?  How is that documented as a requirement?

When the flag is set in a call to RSA_set_method() after a call to RSA_new(), the flag gets ignored with the current implementation.

-Ike-
  John Eichenberger
Intermec by Honeywell
Principal Engineer:?Sustaining Engineering
425.921.4507

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Richard Levitte
Sent: Tuesday, April 03, 2018 7:43 PM
To: openssl-users at openssl.org
Subject: [External] Re: [openssl-users] Correct the check of RSA_FLAG_SIGN_VER

In message <BN6PR07MB3553B5B834436F685450D434F6A50 at BN6PR07MB3553.namprd07.prod.outlook.com> on Tue, 3 Apr 2018 22:55:06 +0000, "Eichenberger, John" <John.Eichenberger at Honeywell.com> said:

John.Eichenberger> Honeywell Internal
John.Eichenberger>
John.Eichenberger> I think I have an answer for why this commit needed to be reverted:
John.Eichenberger>
John.Eichenberger> Author: Dr. Stephen Henson <steve at openssl.org> John.Eichenberger> Author date: 2 years ago (12/20/2015 10:18:43 AM) John.Eichenberger> Commit date: 2 years ago (12/20/2015 11:27:03 AM) John.Eichenberger> Commit hash: 6656ba7152dfe4bba865e327dd362ea08544aa80
John.Eichenberger> Children: 1c7de36f62
John.Eichenberger> Parent(s): 17592f323a John.Eichenberger> John.Eichenberger> Don't check RSA_FLAG_SIGN_VER.
John.Eichenberger>
John.Eichenberger> Reviewed-by: Richard Levitte <levitte at openssl.org> John.Eichenberger> John.Eichenberger> The change made in that commit was to simply remove John.Eichenberger> the attempt to check for the RSA_FLAG_SIGN_VER flag.
John.Eichenberger> But that's not what is wrong with this code that John.Eichenberger> required changing. The change should be to add John.Eichenberger> "meth" prior to flags:

Well, not quite, actually.  We can easily study the code prior to this change by looking at the 1.0.2 source.

1. in RSA_new_method(), which is used to create new instances of the
   RSA structure, there's this line:

    ret->flags = ret->meth->flags & ~RSA_FLAG_NON_FIPS_ALLOW;

   So that makes the check of rsa->flags valid, no need to go via
   rsa->meth

2. In rsa.h (crypto/rsa/rsa.h in 1.0.2), you'll find this comment in
   the middle of the definition of rsa_meth_st

    /*
     * New sign and verify functions: some libraries don't allow arbitrary
     * data to be signed/verified: this allows them to be used. Note: for
     * this to work the RSA_public_decrypt() and RSA_private_encrypt() should
     * *NOT* be used RSA_sign(), RSA_verify() should be used instead. Note:
     * for backwards compatibility this functionality is only enabled if the
     * RSA_FLAG_SIGN_VER option is set in 'flags'.
     */

   Do note the note on backward compatibility...  you see, there were
   versions of OpenSSL where the fields 'rsa_sign' and 'rsa_verify'
   didn't exist (they appeared in OpenSSL 0.9.5), so for the sake of
   allowing older applications to work with the newer OpenSSL without
   recompilation, we required all new RSA method implementations to
   use that flag to have the 'rsa_sign' and 'rsa_verify' functions
   used.  Without that flag, those functions were assumed not to
   exist, that the RSA method structure was pre-0.9.5.  However, this
   was somewhere in 2000.

   Fast forward to 2015, when we were starting to make certain types
   opaque, and someone noticed this flag still hanging around, and we
   figured that 0.9.5 is long gone, and 1.0.1 was a year away from its
   end of life, and we figured that the reason to have this flag at
   all was a matter of years long past, it was time to simply drop its
   use.  It had grown to become irrelevant a long time ago.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/
--
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

From shagunmaheshwariitmec at gmail.com  Thu Apr 12 06:05:05 2018
From: shagunmaheshwariitmec at gmail.com (shagun maheshwari)
Date: Thu, 12 Apr 2018 11:35:05 +0530
Subject: [openssl-users] Open ssl error "hex string is too long invalid hex
	key value"
Message-ID: <CAMYJFZ-qYZZzRVfA8gb89JcROK+pOtqsqZx+8gTYZzRkBrCyWg@mail.gmail.com>

Hi,

We are getting an error "OpenSSL error hex string is too long invalid
hex key value" . OpenSSL version we are using is openssl-1.0.2k-8.el7.
We have solved this issue by applying a patch in openssl package
suggested by openssl community
(https://clicktime.symantec.com/a/1/7Fg4lSHbjGfkPSCbaHTn0_5SA3g7jIxY1-VykXIdKu0=?d=xVjLv3Egby2iJQ8Pps44kijPDpVNeq--5cgHmJMSt7fSfApR2--2rIk1xvvBJSwGIglcjn61v6-JXGiiMB8XDbwUXh0ZdrcNxdLZpZ4iydtMyQvgDDeJdBqNF31hW_gGSt77P5_qmJ2yJH6Z5ycJqZO-sUXRgdvObuqYlAKoqdLqFCSzKnR5BTUYw7C8JvfSp3kLE-Zbr3DSGCEz0KwUBfdYWjeH8n10a4bsKfA8cgMmRr6o9pBR66fciTOnTNJISKm5XTy6SWr9xlsKxJccrczY4TsEDL7AncqGJMaEHWBzFyRbsGWpZmsedW0xIJg0cDSkXGt4xJ3lTN26_iL2qBwfAOarzDrtJ2uQtfOgoszexm-ICb8y8VY23Y7xlvo-6awGNFuZX8xKABbpaB9Q&u=https%3A%2F%2Fmta.openssl.org%2Fpipermail%2Fopenssl-dev%2F2016-May%2F007266.html).

In nwhich release of OpenSSL, we can expect this fix?

Please help.


Regards,

Shagun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180412/494bacd2/attachment.html>

From matt at openssl.org  Thu Apr 12 08:43:07 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 12 Apr 2018 09:43:07 +0100
Subject: [openssl-users] Open ssl error "hex string is too long invalid
 hex key value"
In-Reply-To: <CAMYJFZ-qYZZzRVfA8gb89JcROK+pOtqsqZx+8gTYZzRkBrCyWg@mail.gmail.com>
References: <CAMYJFZ-qYZZzRVfA8gb89JcROK+pOtqsqZx+8gTYZzRkBrCyWg@mail.gmail.com>
Message-ID: <f714f775-105f-aee2-5a5c-25cd7219e676@openssl.org>



On 12/04/18 07:05, shagun maheshwari wrote:
> Hi,
> 
> We are getting an error "OpenSSL error hex string is too long invalid hex key value" . OpenSSL version we are using is openssl-1.0.2k-8.el7. We have solved this issue by applying a patch in openssl package suggested by openssl community (https://clicktime.symantec.com/a/1/7Fg4lSHbjGfkPSCbaHTn0_5SA3g7jIxY1-VykXIdKu0=?d=xVjLv3Egby2iJQ8Pps44kijPDpVNeq--5cgHmJMSt7fSfApR2--2rIk1xvvBJSwGIglcjn61v6-JXGiiMB8XDbwUXh0ZdrcNxdLZpZ4iydtMyQvgDDeJdBqNF31hW_gGSt77P5_qmJ2yJH6Z5ycJqZO-sUXRgdvObuqYlAKoqdLqFCSzKnR5BTUYw7C8JvfSp3kLE-Zbr3DSGCEz0KwUBfdYWjeH8n10a4bsKfA8cgMmRr6o9pBR66fciTOnTNJISKm5XTy6SWr9xlsKxJccrczY4TsEDL7AncqGJMaEHWBzFyRbsGWpZmsedW0xIJg0cDSkXGt4xJ3lTN26_iL2qBwfAOarzDrtJ2uQtfOgoszexm-ICb8y8VY23Y7xlvo-6awGNFuZX8xKABbpaB9Q&u=https%3A%2F%2Fmta.openssl.org%2Fpipermail%2Fopenssl-dev%2F2016-May%2F007266.html). 
> 
> In nwhich release of OpenSSL, we can expect this fix?
> 

The thread you point to doesn't describe a bug in 1.0.2. The command
line provided to OpenSSL in that thread is in error. The hex string
provided for the key is too long (by 2 bytes) so OpenSSL is doing the
right thing by issuing an error message. It seems that this was
tolerated in older versions of OpenSSL (1.0.1) - but that behaviour can
probably be considered a bug in those older (out of support) versions.

Matt


From per.frykenvall at cgi.com  Thu Apr 12 11:12:16 2018
From: per.frykenvall at cgi.com (Frykenvall, Per)
Date: Thu, 12 Apr 2018 11:12:16 +0000
Subject: [openssl-users] How to use ADH with OpenSSL 1.1.0
Message-ID: <28FFB6B5E458CA4C84247B79455AB84D01C3DB0091@SE-EX022.groupinfra.com>

Hi,

I need to permit some anonymous Diffie-Hellman ciphers in OpenSSL. This worked fine until I installed 1.1.0h when I get "no shared cipher". I debugged and found the cause in ssl_security_default_callback, ssl_cert.c line 1028:

            /* No unauthenticated ciphersuites */
            if (c->algorithm_auth & SSL_aNULL)
                return 0;

So do I need to have my own callback, using SSL_CTX_set_security_callback? The manual page is not very informative and I'm not sure about how to implement the callback. I wouldn't like to duplicate all the other checks of the default callback.

Then I tried adding :@SECLEVEL=0 to my cipher suite list. That made the trick, but as far as I understand, it switches off some other cipher checks. What's the recommended way of allowing ADH?

Best regards,
Per


From openssl-users at dukhovni.org  Thu Apr 12 17:05:38 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 12 Apr 2018 13:05:38 -0400
Subject: [openssl-users] How to use ADH with OpenSSL 1.1.0
In-Reply-To: <28FFB6B5E458CA4C84247B79455AB84D01C3DB0091@SE-EX022.groupinfra.com>
References: <28FFB6B5E458CA4C84247B79455AB84D01C3DB0091@SE-EX022.groupinfra.com>
Message-ID: <6BBF8925-90A1-429F-BC4F-F767609DE64C@dukhovni.org>



> On Apr 12, 2018, at 7:12 AM, Frykenvall, Per <per.frykenvall at cgi.com> wrote:
> 
> Then I tried adding :@SECLEVEL=0 to my cipher suite list. That made the trick, but as far as I understand, it switches off some other cipher checks. What's the recommended way of allowing ADH?

For now just @SECLEVEL=0.  There's not yet a more fine-grained to set the security level for crypto parameters but allow certificate-less key exchange.  If you're willing to allow MiTM attacks, then downgrades are of scope, and the peers will negotiate the best available ciphers, so @SECLEVEL=0 is probably fine, you'll still get strong ciphers.
You can also limit the cipher list to exclude anything you feel is too weak to offer.

-- 
	Viktor.


From bill.c.roberts at gmail.com  Fri Apr 13 16:17:28 2018
From: bill.c.roberts at gmail.com (William Roberts)
Date: Fri, 13 Apr 2018 09:17:28 -0700
Subject: [openssl-users] engine interface for genrsa
Message-ID: <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8+YQ@mail.gmail.com>

I am currently working on writing an openssl engine
to interface with a piece of hardware.

I am trying to understand how to implement
rsa key generation, where the private key
bytes would not be available.

I am currently invoking the
command:

openssl genrsa -engine foo

Which is calling my callback for RSA keygen, registered via ENGINE_set_RSA()
and I set the flags: RSA_FLAG_EXT_PKEY.

However, genrsa app seems to want rsa->e set here:
https://github.com/openssl/openssl/blob/OpenSSL_1_0_2g/apps/genrsa.c#L291

I can't find documentation on how to handle the keygen interface
for RSA.

Can someone point me in the right direction?

Thanks,
Bill

From pratyush.parimal at gmail.com  Fri Apr 13 18:53:25 2018
From: pratyush.parimal at gmail.com (pratyush parimal)
Date: Fri, 13 Apr 2018 14:53:25 -0400
Subject: [openssl-users] Should I stop using locking callbacks in OpenSSL
	1.1.0x ?
Message-ID: <CALvRNOG0kVoYb-VNHpeoE5+2HA6cav4WhkH5dD9WW6Bsn=5fkQ@mail.gmail.com>

Hi all,

I'm trying to migrate some application code from OpenSSL 1.0.1e to 1.1.0g.
I keep seeing that the locking and threading callbacks I had used earlier
(with CRYPTO_set_locking_callback and CRYPTO_set_id_callback respectively)
now show up as "unused" during compilation.

I checked https://www.openssl.org/blog/blog/2017/02/21/threads/ and it
seems like OpenSSL is trying to ditch callbacks and use more native
facilities. In 1.1.0g's crypto.h, CRYPTO_set_locking_callback is defined as
a no-op, with the following comment:

/*
 * The old locking functions have been removed completely without
compatibility
 * macros. This is because the old functions either could not properly
report
 * errors, or the returned error values were not clearly documented.
 * Replacing the locking functions with with no-ops would cause race
condition
 * issues in the affected applications. It is far better for them to fail at
 * compile time.
 * On the other hand, the locking callbacks are no longer used.
Consequently,
 * the callback management functions can be safely replaced with no-op
macros.
 */

Does this mean I can safely remove all usages of the above functions from
my application code? I'd appreciate if someone could explain the above
comment in a little more detail or confirm what I'm saying. Or has anyone
else been in the same situation?

Thanks,
Pratyush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180413/7ed557c9/attachment.html>

From rsalz at akamai.com  Fri Apr 13 19:22:23 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 13 Apr 2018 19:22:23 +0000
Subject: [openssl-users] Should I stop using locking callbacks in
 OpenSSL 1.1.0x ?
In-Reply-To: <CALvRNOG0kVoYb-VNHpeoE5+2HA6cav4WhkH5dD9WW6Bsn=5fkQ@mail.gmail.com>
References: <CALvRNOG0kVoYb-VNHpeoE5+2HA6cav4WhkH5dD9WW6Bsn=5fkQ@mail.gmail.com>
Message-ID: <FF50F98D-6D3F-4013-A3E9-57090C31381E@akamai.com>



  *   Does this mean I can safely remove all usages of the above functions from my application code? I'd appreciate if someone could explain the above comment in a little more detail or confirm what I'm saying. Or has anyone else been in the same situation?

Yes.  Do not use the locking callbacks.  OpenSSL uses system-native threads and locks now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180413/fba81ffe/attachment.html>

From charlesm at mcn.org  Fri Apr 13 21:35:40 2018
From: charlesm at mcn.org (Charles Mills)
Date: Fri, 13 Apr 2018 17:35:40 -0400
Subject: [openssl-users] Should I stop using locking callbacks in
 OpenSSL 1.1.0x ?
In-Reply-To: <FF50F98D-6D3F-4013-A3E9-57090C31381E@akamai.com>
Message-ID: <20180413214228.029F2E62E1@mta.openssl.org>

?Not to disagree of course,? but you can always put printf's in your callbacks to confirm.?



CharlesSent from a mobile; please excuse the brevity.
-------- Original message --------From: "Salz, Rich via openssl-users" <openssl-users at openssl.org> Date: 4/13/18  3:22 PM  (GMT-05:00) To: openssl-users at openssl.org Subject: Re: [openssl-users] Should I stop using locking callbacks in OpenSSL 1.1.0x ? 


?


Does this mean I can safely remove all usages of the above functions from my application code? I'd appreciate if someone could explain
 the above comment in a little more detail or confirm what I'm saying. Or has anyone else been in the same situation?


?
Yes.? Do not use the locking callbacks.? OpenSSL uses system-native threads and locks now.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180413/54056a5c/attachment.html>

From levitte at openssl.org  Fri Apr 13 21:55:55 2018
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 13 Apr 2018 23:55:55 +0200 (CEST)
Subject: [openssl-users] engine interface for genrsa
In-Reply-To: <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8+YQ@mail.gmail.com>
References: <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8+YQ@mail.gmail.com>
Message-ID: <20180413.235555.817780897856405713.levitte@openssl.org>

In message <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8+YQ at mail.gmail.com> on Fri, 13 Apr 2018 09:17:28 -0700, William Roberts <bill.c.roberts at gmail.com> said:

bill.c.roberts> I am currently working on writing an openssl engine
bill.c.roberts> to interface with a piece of hardware.
bill.c.roberts> 
bill.c.roberts> I am trying to understand how to implement
bill.c.roberts> rsa key generation, where the private key
bill.c.roberts> bytes would not be available.
bill.c.roberts> 
bill.c.roberts> I am currently invoking the
bill.c.roberts> command:
bill.c.roberts> 
bill.c.roberts> openssl genrsa -engine foo
bill.c.roberts> 
bill.c.roberts> Which is calling my callback for RSA keygen, registered via ENGINE_set_RSA()
bill.c.roberts> and I set the flags: RSA_FLAG_EXT_PKEY.
bill.c.roberts> 
bill.c.roberts> However, genrsa app seems to want rsa->e set here:
bill.c.roberts> https://github.com/openssl/openssl/blob/OpenSSL_1_0_2g/apps/genrsa.c#L291
bill.c.roberts> 
bill.c.roberts> I can't find documentation on how to handle the keygen interface
bill.c.roberts> for RSA.
bill.c.roberts> 
bill.c.roberts> Can someone point me in the right direction?

e and n are public components of any RSA key pair (and RSA structure
in OpenSSL).  You *must* make them available.  The rest of the numbers
are private and do not need to be part of the RSA structure that
OpenSSL handles.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Fri Apr 13 22:33:59 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 13 Apr 2018 22:33:59 +0000
Subject: [openssl-users] Should I stop using locking callbacks in
 OpenSSL 1.1.0x ?
In-Reply-To: <201804132135.w3DLWSl3025481@m0050102.ppops.net-00190b01.>
References: <FF50F98D-6D3F-4013-A3E9-57090C31381E@akamai.com>
 <201804132135.w3DLWSl3025481@m0050102.ppops.net-00190b01.>
Message-ID: <2BAB7518-2644-4388-9D3B-6721991C6A91@akamai.com>

OpenSSL 1.1.0 *does not* go through the locking callbacks.  They will never be called.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180413/3bfe10d1/attachment-0001.html>

From bill.c.roberts at gmail.com  Sat Apr 14 00:28:38 2018
From: bill.c.roberts at gmail.com (William Roberts)
Date: Fri, 13 Apr 2018 17:28:38 -0700
Subject: [openssl-users] engine interface for genrsa
In-Reply-To: <20180413.235555.817780897856405713.levitte@openssl.org>
References: <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8+YQ@mail.gmail.com>
 <20180413.235555.817780897856405713.levitte@openssl.org>
Message-ID: <CAFftDdrUQDyeauY+pxvRGUkFyXuFLJj-M_7PMjOzn9SMATuM-A@mail.gmail.com>

On Fri, Apr 13, 2018 at 2:55 PM, Richard Levitte <levitte at openssl.org> wrote:
> In message <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8+YQ at mail.gmail.com> on Fri, 13 Apr 2018 09:17:28 -0700, William Roberts <bill.c.roberts at gmail.com> said:
>
> bill.c.roberts> I am currently working on writing an openssl engine
> bill.c.roberts> to interface with a piece of hardware.
> bill.c.roberts>
> bill.c.roberts> I am trying to understand how to implement
> bill.c.roberts> rsa key generation, where the private key
> bill.c.roberts> bytes would not be available.
> bill.c.roberts>
> bill.c.roberts> I am currently invoking the
> bill.c.roberts> command:
> bill.c.roberts>
> bill.c.roberts> openssl genrsa -engine foo
> bill.c.roberts>
> bill.c.roberts> Which is calling my callback for RSA keygen, registered via ENGINE_set_RSA()
> bill.c.roberts> and I set the flags: RSA_FLAG_EXT_PKEY.
> bill.c.roberts>
> bill.c.roberts> However, genrsa app seems to want rsa->e set here:
> bill.c.roberts> https://github.com/openssl/openssl/blob/OpenSSL_1_0_2g/apps/genrsa.c#L291
> bill.c.roberts>
> bill.c.roberts> I can't find documentation on how to handle the keygen interface
> bill.c.roberts> for RSA.
> bill.c.roberts>
> bill.c.roberts> Can someone point me in the right direction?
>
> e and n are public components of any RSA key pair (and RSA structure
> in OpenSSL).  You *must* make them available.  The rest of the numbers
> are private and do not need to be part of the RSA structure that
> OpenSSL handles.

Thanks. I went and read the RSA page on Wikipedia, and sure enough it
has what common meanings of what all the single letter variables
are in the RSA struct.
https://en.wikipedia.org/wiki/RSA_(cryptosystem)

>
> Cheers,
> Richard
>
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From per.frykenvall at cgi.com  Sat Apr 14 08:57:23 2018
From: per.frykenvall at cgi.com (Frykenvall, Per)
Date: Sat, 14 Apr 2018 08:57:23 +0000
Subject: [openssl-users] How to use ADH with OpenSSL 1.1.0
In-Reply-To: <6BBF8925-90A1-429F-BC4F-F767609DE64C@dukhovni.org>
References: <28FFB6B5E458CA4C84247B79455AB84D01C3DB0091@SE-EX022.groupinfra.com>
 <6BBF8925-90A1-429F-BC4F-F767609DE64C@dukhovni.org>
Message-ID: <28FFB6B5E458CA4C84247B79455AB84D01C3DB0DDE@SE-EX022.groupinfra.com>

>> Then I tried adding :@SECLEVEL=0 to my cipher suite list. That made the trick, but as far as I understand, it switches off some other cipher checks. What's the recommended way of allowing ADH?

>For now just @SECLEVEL=0.  There's not yet a more fine-grained to set the security 
>level for crypto parameters but allow certificate-less key exchange.  If you're willing
>to allow MiTM attacks, then downgrades are of scope, and the peers will negotiate
>the best available ciphers, so @SECLEVEL=0 is probably fine, you'll still get strong ciphers.
>You can also limit the cipher list to exclude anything you feel is too weak to offer.

Since we never allow unauthenticated cipher suites in production configurations, it's actually not a problem with the @SECLEVEL solution for those test systems where we do use ADH. Glad that I don't have to use a modified callback.
Thanks a lot, Per


From Marcus.Schafheutle at gmx.de  Mon Apr 16 08:19:20 2018
From: Marcus.Schafheutle at gmx.de (Marcus.Schafheutle at gmx.de)
Date: Mon, 16 Apr 2018 10:19:20 +0200
Subject: [openssl-users] OpenSSL 1.1.0 assertion failure:
	ssl_free_wbio_buffer()
Message-ID: <trinity-6f614d59-c503-49ca-b474-a95ce1d1d517-1523866760271@3c-app-gmx-bs37>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180416/914ca787/attachment.html>

From matt at openssl.org  Mon Apr 16 10:38:34 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 Apr 2018 11:38:34 +0100
Subject: [openssl-users] OpenSSL 1.1.0 assertion failure:
 ssl_free_wbio_buffer()
In-Reply-To: <trinity-6f614d59-c503-49ca-b474-a95ce1d1d517-1523866760271@3c-app-gmx-bs37>
References: <trinity-6f614d59-c503-49ca-b474-a95ce1d1d517-1523866760271@3c-app-gmx-bs37>
Message-ID: <e658ee05-202c-f3e5-ac98-8072572cbcf0@openssl.org>



On 16/04/18 09:19, Marcus.Schafheutle at gmx.de wrote:
> SSL_set_bio(ssl, NULL, NULL); // free BIOs when finished

There should be no reason to do this. The BIO's will get freed
automatically by the SSL_free() call.


> Is this a faulty behavior of OpenSSL 1.1.0 or is the fault on my side??


This looks like a bug in OpenSSL. It should be able to tolerate passing
NULL for wbio in the SSL_set_bio call, but apparently it can't in the
case of a failed handshake. Please could you open an issue on github for
this?

The workaround is to remove the SSL_set_bio(SSL, NULL, NULL) call. It
should not be necessary.

Matt


From matt at openssl.org  Mon Apr 16 13:15:38 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 Apr 2018 14:15:38 +0100
Subject: [openssl-users] OpenSSL 1.1.0 assertion failure:
 ssl_free_wbio_buffer()
In-Reply-To: <e658ee05-202c-f3e5-ac98-8072572cbcf0@openssl.org>
References: <trinity-6f614d59-c503-49ca-b474-a95ce1d1d517-1523866760271@3c-app-gmx-bs37>
 <e658ee05-202c-f3e5-ac98-8072572cbcf0@openssl.org>
Message-ID: <6260c8d4-6259-114b-72e1-20b58c475750@openssl.org>



On 16/04/18 11:38, Matt Caswell wrote:
> 
> 
> On 16/04/18 09:19, Marcus.Schafheutle at gmx.de wrote:
>> SSL_set_bio(ssl, NULL, NULL); // free BIOs when finished
> 
> There should be no reason to do this. The BIO's will get freed
> automatically by the SSL_free() call.
> 
> 
>> Is this a faulty behavior of OpenSSL 1.1.0 or is the fault on my side??
> 
> 
> This looks like a bug in OpenSSL. It should be able to tolerate passing
> NULL for wbio in the SSL_set_bio call, but apparently it can't in the
> case of a failed handshake. Please could you open an issue on github for
> this?
> 
> The workaround is to remove the SSL_set_bio(SSL, NULL, NULL) call. It
> should not be necessary.

I created a fix and some tests here:

https://github.com/openssl/openssl/pull/5966

It turns out the assertion is completely bogus and can simply be removed.

Matt


From openssl at openssl.org  Mon Apr 16 15:36:47 2018
From: openssl at openssl.org (OpenSSL)
Date: Mon, 16 Apr 2018 15:36:47 +0000
Subject: [openssl-users] OpenSSL Security Advisory
Message-ID: <20180416153647.GA21276@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


OpenSSL Security Advisory [16 Apr 2018]
========================================

Cache timing vulnerability in RSA Key Generation (CVE-2018-0737)
================================================================

Severity: Low

The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to a
cache timing side channel attack. An attacker with sufficient access to mount
cache timing attacks during the RSA key generation process could recover the
private key.

Due to the low severity of this issue we are not issuing a new release of
OpenSSL 1.1.0 or 1.0.2 at this time. The fix will be included in OpenSSL 1.1.0i
and OpenSSL 1.0.2p when they become available. The fix is also available in
commit 6939eab03 (for 1.1.0) and commit 349a41da1 (for 1.0.2) in the OpenSSL git
repository.

This issue was reported to OpenSSL on 4th April 2018 by Alejandro Cabrera
Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia.
The fix was developed by Billy Brumley.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20180416.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJa1MKgAAoJENnE0m0OYESRKOoIAKmRnj0YtE1y89WnRiCjMk8l
Z7XAsPk6nkEa8dlrEvEsUhS90CFSf9OcYliAlfjD/+RVZXXeK4AHn8/g7HxAdDcK
62biQiHbxICBqnrE6DCe6GrMXEy3MWuefSWnoTyd/x8W1grjdhkrlmIqe68DP0iv
WItmStRVOpx4mQDcrYqw6ZKhhu1Lv007khyAornJP+S6NSlK6brdNQyRNmp3+HO4
irqPi6xQWGcaAtrdpWi8mDnomld75j5m+G98N/gCqaCAIn7Zau+kAAW1+1dO5S4L
tsQ0CifVnRfUTz0cCL51L8G3a3RWYs34AXRZvSRi3q88AiZ1L6FCF2cHZJu1KuE=
=+TYO
-----END PGP SIGNATURE-----

From scott_n at xypro.com  Mon Apr 16 15:59:58 2018
From: scott_n at xypro.com (Scott Neugroschl)
Date: Mon, 16 Apr 2018 15:59:58 +0000
Subject: [openssl-users] CVE-201-0737
Message-ID: <D358E5B1511A314F8160ADC6F3754987010B4BA5B5@XYSVEX02.XYPRO-23.LOCAL>

Hi,

I'm trying to make sure I have grokked this advisory properly.

The advisory says this is a cache timing side channel attack on key generation.   So am I correct in assuming that a potential attacker must

1) Already have access to the system
2) Have sufficient privilege to be able to access cache info

Or am I completely mistaken here?

Thanks,

ScottN

---
Scott Neugroschl | XYPRO Technology Corporation
4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |




From matt at openssl.org  Mon Apr 16 16:35:09 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 Apr 2018 17:35:09 +0100
Subject: [openssl-users] CVE-201-0737
In-Reply-To: <D358E5B1511A314F8160ADC6F3754987010B4BA5B5@XYSVEX02.XYPRO-23.LOCAL>
References: <D358E5B1511A314F8160ADC6F3754987010B4BA5B5@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <e941a36f-d7cc-4ba2-28f4-354a50d9268b@openssl.org>



On 16/04/18 16:59, Scott Neugroschl wrote:
> Hi,
> 
> I'm trying to make sure I have grokked this advisory properly.
> 
> The advisory says this is a cache timing side channel attack on key generation.   So am I correct in assuming that a potential attacker must
> 
> 1) Already have access to the system
> 2) Have sufficient privilege to be able to access cache info

Correct.

Matt


From scott_n at xypro.com  Mon Apr 16 18:18:34 2018
From: scott_n at xypro.com (Scott Neugroschl)
Date: Mon, 16 Apr 2018 18:18:34 +0000
Subject: [openssl-users] CVE-201-0737
In-Reply-To: <e941a36f-d7cc-4ba2-28f4-354a50d9268b@openssl.org>
References: <D358E5B1511A314F8160ADC6F3754987010B4BA5B5@XYSVEX02.XYPRO-23.LOCAL>
 <e941a36f-d7cc-4ba2-28f4-354a50d9268b@openssl.org>
Message-ID: <D358E5B1511A314F8160ADC6F3754987010B4BA625@XYSVEX02.XYPRO-23.LOCAL>


On 16/04/18 0935PDT, Matt Caswell wrote:
>On 16/04/18 16:59, Scott Neugroschl wrote:
>> Hi,
>> 
>> I'm trying to make sure I have grokked this advisory properly.
>> 
>> The advisory says this is a cache timing side channel attack on key generation.   So am I correct in assuming that a potential attacker must
>> 
>> 1) Already have access to the system
>> 2) Have sufficient privilege to be able to access cache info
>
>Correct.

Thanks, Matt!


---
Scott Neugroschl | XYPRO Technology Corporation
4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |




From rob.marshall17 at gmail.com  Mon Apr 16 18:27:17 2018
From: rob.marshall17 at gmail.com (Rob Marshall)
Date: Mon, 16 Apr 2018 14:27:17 -0400
Subject: [openssl-users] What does this error mean?
Message-ID: <CALrmp7xHdfwBCRzJDmbXvT=WMkwVjqgac+ZHkPyLD=esPasp2w@mail.gmail.com>

Hi,

It may not be relevant, but I'm running SLES 10 SP3 which is a very
old version of the OS and I can't upgrade it due to some installed
products. When I try to do a wget I'm seeing the error:

OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
alert protocol version

What does the error mean and how do I fix it?

Thanks,

Rob

From Michael.Wojcik at microfocus.com  Mon Apr 16 18:38:03 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Mon, 16 Apr 2018 18:38:03 +0000
Subject: [openssl-users] What does this error mean?
In-Reply-To: <CALrmp7xHdfwBCRzJDmbXvT=WMkwVjqgac+ZHkPyLD=esPasp2w@mail.gmail.com>
References: <CALrmp7xHdfwBCRzJDmbXvT=WMkwVjqgac+ZHkPyLD=esPasp2w@mail.gmail.com>
Message-ID: <SN1PR18MB2112CC33099B58A2B5A58EFDF9B00@SN1PR18MB2112.namprd18.prod.outlook.com>

The server is rejecting the connection because it doesn't like the SSL/TLS version range that wget is offering. Anything prior to TLSv1.1 suffers from vulnerabilities that can be exploited under practical conditions, so many servers reject older protocol versions.


You don't have to upgrade the OS to put a newer version of OpenSSL on, though you may have to build OpenSSL yourself.

________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Rob Marshall <rob.marshall17 at gmail.com>
Sent: Monday, April 16, 2018 2:27:17 PM
To: openssl-users at openssl.org
Subject: [openssl-users] What does this error mean?

Hi,

It may not be relevant, but I'm running SLES 10 SP3 which is a very
old version of the OS and I can't upgrade it due to some installed
products. When I try to do a wget I'm seeing the error:

OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
alert protocol version

What does the error mean and how do I fix it?

Thanks,

Rob
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180416/6dc2069c/attachment.html>

From meissner at suse.de  Mon Apr 16 18:33:25 2018
From: meissner at suse.de (Marcus Meissner)
Date: Mon, 16 Apr 2018 20:33:25 +0200
Subject: [openssl-users] What does this error mean?
In-Reply-To: <CALrmp7xHdfwBCRzJDmbXvT=WMkwVjqgac+ZHkPyLD=esPasp2w@mail.gmail.com>
References: <CALrmp7xHdfwBCRzJDmbXvT=WMkwVjqgac+ZHkPyLD=esPasp2w@mail.gmail.com>
Message-ID: <20180416183325.7g3foy35fdj5vezl@suse.de>

On Mon, Apr 16, 2018 at 02:27:17PM -0400, Rob Marshall wrote:
> Hi,
> 
> It may not be relevant, but I'm running SLES 10 SP3 which is a very
> old version of the OS and I can't upgrade it due to some installed
> products. When I try to do a wget I'm seeing the error:
> 
> OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
> alert protocol version
> 
> What does the error mean and how do I fix it?

>From which host? The host probably only speaks TLS 1.2.

Ciao, Marcus

From rob.marshall17 at gmail.com  Mon Apr 16 20:22:53 2018
From: rob.marshall17 at gmail.com (Rob Marshall)
Date: Mon, 16 Apr 2018 16:22:53 -0400
Subject: [openssl-users] What does this error mean?
In-Reply-To: <20180416183325.7g3foy35fdj5vezl@suse.de>
References: <CALrmp7xHdfwBCRzJDmbXvT=WMkwVjqgac+ZHkPyLD=esPasp2w@mail.gmail.com>
 <20180416183325.7g3foy35fdj5vezl@suse.de>
Message-ID: <CALrmp7w0BhSdzm5m6f2jpC6ARspF9Du+t6fxES6-pQ7Cxuamdw@mail.gmail.com>

Hi,

I built and installed OpenSSL 1.0.2n and I'm still seeing the problem.
I originally tried to build/install 1.1.0h but my goal was to
build/install an updated OpenSSH (7.7.p1) and it wouldn't build with
that version and a straight 1.1.0 build failed. So I went with the
most recent 1.0.2 (in this case n) that I could find.

Rob

On Mon, Apr 16, 2018 at 2:33 PM, Marcus Meissner <meissner at suse.de> wrote:
> On Mon, Apr 16, 2018 at 02:27:17PM -0400, Rob Marshall wrote:
>> Hi,
>>
>> It may not be relevant, but I'm running SLES 10 SP3 which is a very
>> old version of the OS and I can't upgrade it due to some installed
>> products. When I try to do a wget I'm seeing the error:
>>
>> OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
>> alert protocol version
>>
>> What does the error mean and how do I fix it?
>
> From which host? The host probably only speaks TLS 1.2.
>
> Ciao, Marcus
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From Michael.Wojcik at microfocus.com  Mon Apr 16 21:17:35 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Mon, 16 Apr 2018 21:17:35 +0000
Subject: [openssl-users] What does this error mean?
In-Reply-To: <CALrmp7w0BhSdzm5m6f2jpC6ARspF9Du+t6fxES6-pQ7Cxuamdw@mail.gmail.com>
References: <CALrmp7xHdfwBCRzJDmbXvT=WMkwVjqgac+ZHkPyLD=esPasp2w@mail.gmail.com>
 <20180416183325.7g3foy35fdj5vezl@suse.de>,
 <CALrmp7w0BhSdzm5m6f2jpC6ARspF9Du+t6fxES6-pQ7Cxuamdw@mail.gmail.com>
Message-ID: <SN1PR18MB2112AD99876EA8FB2C47D742F9B00@SN1PR18MB2112.namprd18.prod.outlook.com>

It may be how the (probably somewhat outdated) version of wget is using the openssl API. Try "openssl s_client -connect server:port", using the server and port you're trying to get wget to connect to.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180416/c2146bf6/attachment.html>

From rob.marshall17 at gmail.com  Mon Apr 16 21:30:09 2018
From: rob.marshall17 at gmail.com (Rob Marshall)
Date: Mon, 16 Apr 2018 17:30:09 -0400
Subject: [openssl-users] What does this error mean?
In-Reply-To: <SN1PR18MB2112AD99876EA8FB2C47D742F9B00@SN1PR18MB2112.namprd18.prod.outlook.com>
References: <CALrmp7xHdfwBCRzJDmbXvT=WMkwVjqgac+ZHkPyLD=esPasp2w@mail.gmail.com>
 <20180416183325.7g3foy35fdj5vezl@suse.de>
 <CALrmp7w0BhSdzm5m6f2jpC6ARspF9Du+t6fxES6-pQ7Cxuamdw@mail.gmail.com>
 <SN1PR18MB2112AD99876EA8FB2C47D742F9B00@SN1PR18MB2112.namprd18.prod.outlook.com>
Message-ID: <CALrmp7ybK8p0Yr_R1Yzpo8VHWv5j3RkDBDdQW8kYO+ohGdgmnA@mail.gmail.com>

Hi,

When I do that I see, among other things:

...
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 9B63040F2D2F498F610A84E4A9D9017AF375772DFDDA760378666391A17C2C75
...

When I tried to force TLSv1.2 I got:

hostname:~ # wget --no-check-certificate --secure-protocol=TLSv1_2
https://bootstrap.pypa.io/get-pip.py
wget: --secure-protocol: Invalid value `TLSv1_2'.

My guess is that it's just too old of a version of wget. I was going
to try to build/install a newer version, but it seems to have
prerequisites I can't meet on SLES 10 SP3.

Thanks,

Rob

On Mon, Apr 16, 2018 at 5:17 PM, Michael Wojcik
<Michael.Wojcik at microfocus.com> wrote:
> It may be how the (probably somewhat outdated) version of wget is using the
> openssl API. Try "openssl s_client -connect server:port", using the server
> and port you're trying to get wget to connect to.
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

From rsalz at akamai.com  Mon Apr 16 21:53:57 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 16 Apr 2018 21:53:57 +0000
Subject: [openssl-users] What does this error mean?
In-Reply-To: <CALrmp7w0BhSdzm5m6f2jpC6ARspF9Du+t6fxES6-pQ7Cxuamdw@mail.gmail.com>
References: <CALrmp7xHdfwBCRzJDmbXvT=WMkwVjqgac+ZHkPyLD=esPasp2w@mail.gmail.com>
 <20180416183325.7g3foy35fdj5vezl@suse.de>
 <CALrmp7w0BhSdzm5m6f2jpC6ARspF9Du+t6fxES6-pQ7Cxuamdw@mail.gmail.com>
Message-ID: <22722B4C-1B15-4C05-B587-C9963504D6D9@akamai.com>

You didn't answer the question that was asked.

Which host?

?On 4/16/18, 4:23 PM, "Rob Marshall" <rob.marshall17 at gmail.com> wrote:

    Hi,
    
    I built and installed OpenSSL 1.0.2n and I'm still seeing the problem.
    I originally tried to build/install 1.1.0h but my goal was to
    build/install an updated OpenSSH (7.7.p1) and it wouldn't build with
    that version and a straight 1.1.0 build failed. So I went with the
    most recent 1.0.2 (in this case n) that I could find.
    
    Rob
    
    On Mon, Apr 16, 2018 at 2:33 PM, Marcus Meissner <meissner at suse.de> wrote:
    > On Mon, Apr 16, 2018 at 02:27:17PM -0400, Rob Marshall wrote:
    >> Hi,
    >>
    >> It may not be relevant, but I'm running SLES 10 SP3 which is a very
    >> old version of the OS and I can't upgrade it due to some installed
    >> products. When I try to do a wget I'm seeing the error:
    >>
    >> OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
    >> alert protocol version
    >>
    >> What does the error mean and how do I fix it?
    >
    > From which host? The host probably only speaks TLS 1.2.
    >
    > Ciao, Marcus
    > --
    > 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
    


From rob.marshall17 at gmail.com  Mon Apr 16 22:02:39 2018
From: rob.marshall17 at gmail.com (Rob Marshall)
Date: Mon, 16 Apr 2018 18:02:39 -0400
Subject: [openssl-users] What does this error mean?
In-Reply-To: <22722B4C-1B15-4C05-B587-C9963504D6D9@akamai.com>
References: <CALrmp7xHdfwBCRzJDmbXvT=WMkwVjqgac+ZHkPyLD=esPasp2w@mail.gmail.com>
 <20180416183325.7g3foy35fdj5vezl@suse.de>
 <CALrmp7w0BhSdzm5m6f2jpC6ARspF9Du+t6fxES6-pQ7Cxuamdw@mail.gmail.com>
 <22722B4C-1B15-4C05-B587-C9963504D6D9@akamai.com>
Message-ID: <CALrmp7wDw23MB2UNVZonZWzQNMdr7B9kQqbcGuLxBE_QMCqomA@mail.gmail.com>

Hi,

The command I'm running is:

wget --no-check-certificate https://bootstrap.pypa.io/get-pip.py

So in this particular case the host is: bootstrap.pypa.io. I was
trying to install the Python pip command.

Rob

On Mon, Apr 16, 2018 at 5:53 PM, Salz, Rich via openssl-users
<openssl-users at openssl.org> wrote:
> You didn't answer the question that was asked.
>
> Which host?
>
> ?On 4/16/18, 4:23 PM, "Rob Marshall" <rob.marshall17 at gmail.com> wrote:
>
>     Hi,
>
>     I built and installed OpenSSL 1.0.2n and I'm still seeing the problem.
>     I originally tried to build/install 1.1.0h but my goal was to
>     build/install an updated OpenSSH (7.7.p1) and it wouldn't build with
>     that version and a straight 1.1.0 build failed. So I went with the
>     most recent 1.0.2 (in this case n) that I could find.
>
>     Rob
>
>     On Mon, Apr 16, 2018 at 2:33 PM, Marcus Meissner <meissner at suse.de> wrote:
>     > On Mon, Apr 16, 2018 at 02:27:17PM -0400, Rob Marshall wrote:
>     >> Hi,
>     >>
>     >> It may not be relevant, but I'm running SLES 10 SP3 which is a very
>     >> old version of the OS and I can't upgrade it due to some installed
>     >> products. When I try to do a wget I'm seeing the error:
>     >>
>     >> OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
>     >> alert protocol version
>     >>
>     >> What does the error mean and how do I fix it?
>     >
>     > From which host? The host probably only speaks TLS 1.2.
>     >
>     > Ciao, Marcus
>     > --
>     > 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 mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From ct06fr at gmail.com  Tue Apr 17 12:30:17 2018
From: ct06fr at gmail.com (Christophe Truc)
Date: Tue, 17 Apr 2018 14:30:17 +0200
Subject: [openssl-users] ALPN and SSL_set_SSL_CTX
Message-ID: <CAF4CTYDZLiPne4GvtGQdWGhAH9UuJoN7+2Kj3nSVOBzJ28pUYw@mail.gmail.com>

 Hi!

My application server can receive 2 types of incoming connections, either
from user requests (such as Firefox) or from a proprietary client for which
the HTTP requests are controlled. I want to enforce client verification for
the proprietary client connections, not for the user requests.
Unfortunately, I have very few possibilities for determining the connection
type, everybody connect on the same TCP port.

Because I control the proprietary client connections, I tries using the
ALPN extension. In this case, my application server can detect the ALPN
extension and enforce the client verification. In order to implement this,
I tried using SSL_set_SSL_CTX in the ALPN callback. Because this function
does not seem to copy the verify_mode flag, I also applied SSL_set_verify
and SSL_set_verify_depth on the SSL handle.

The client certificate is requested and verified but OpenSSL then fails
with an internal error. I managed to make it work with the same mechanism
applied to SNI. My questions are:
   - Is it expected to have the error when using the ALPN callback? i had
the feeling that it would be more appropriate to use this extension in this
case.
   - Is it valid to use SNI this way? The registered server_name is an
ASCII keyword used to detect the inbound request type, not a real server
name.

Thank you,
Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180417/fc74d67d/attachment-0001.html>

From openssl at openssl.org  Tue Apr 17 14:04:50 2018
From: openssl at openssl.org (OpenSSL)
Date: Tue, 17 Apr 2018 14:04:50 +0000
Subject: [openssl-users] OpenSSL verssion 1.1.1 pre release 5 published
Message-ID: <20180417140450.GA15737@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


   OpenSSL version 1.1.1 pre release 5 (beta)
   ===========================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 5 has now
   been made available. For details of changes and known issues see the
   release notes at:

        https://www.openssl.org/news/openssl-1.1.1-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The beta release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.1-pre5.tar.gz
      Size: 8288689
      SHA1 checksum: 8b479a8c555a9eba57b6003e4bd7200dff9535ee
      SHA256 checksum: 0e5ff2f216cea5fa89af6dcd429c3c142acd7c786b0c4868a039689a2641cf3d

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.1-pre5.tar.gz
    openssl sha256 openssl-1.1.1-pre5.tar.gz

   Please download and check this beta release as soon as possible.
   To report a bug, open an issue on GitHub:

    https://github.com/openssl/openssl/issues

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlrV93QACgkQ1enkP335
7owHBBAArOo3ChdJyOVRNN9wXPgRJtDTTv22yqadmcgpEiwh5AMWZUCg9Tl8B0BZ
mMcQruV1J0m5qi4mUgBp87ZhqCcOje7uZubyj6VKEAxlklIzyrfPaJyIUWE7CwQi
6jPrMrF9PVkj24DZ/IUPFk6+fJen9POJddeaCuxUM12faZkRD0XxxTEvyKamgou7
Odb/Zn148SFQKMMSVOgaSr0t/go9gJ3vNRaRzBUhG9ZSaxDcwzCaO5OjjwI4xrEY
XnGT54yWJNIvnSsxddhs7q4AUDEa/jNq+iCduPYVbMfuym+7YYMTlKABfnP5i1D2
gd8Ag+2hJe7rtKB6vYKOnyTKJFoMLhoRfJ12N55fJ9L4yLoy5guZEelE2Ib35YWo
twlgQVPu5YnJpZnF0uZTZmcOJruEcQ7e15B8zyZfUIBtqXXg3tcH3QD3noKUYVmf
s8+EfwebwIoLCy8kriO5bogJRVLQHvu1gehTXQa3edrD7iinZzlhdR7UPl9avlnv
7A0XhEiPEqwEmJUdHx/NGH5bydx/cb+oRgB26YTQyqhNw0meQg4znTui/xz2ARE/
r7PWifGhPPAbq8txuj+d8ipDeoyXS46KgR+sF2ncYMS3iQpAddQtCFIU1whpeRip
wGm9uMu41Ba0H3CmUbmgTNU5kE3RCR00kirPiGQfRtf/pwI5zZY=
=vyz+
-----END PGP SIGNATURE-----

From bill at panix.com  Tue Apr 17 21:18:36 2018
From: bill at panix.com (Bill Kurland)
Date: Tue, 17 Apr 2018 17:18:36 -0400
Subject: [openssl-users] ar : File format not recognized
Message-ID: <bfd227ef-4436-26c2-ac21-d67e3ec7d4c8@panix.com>

I'm trying to build openssl-1.1.0h on AIX 6.1 with the ultimate goal of 
building the IO::Socket::SSL perl module.

make fails when creating libcrypto.a and libssl.a because, it seems, the 
*.o files are in a format not recognized by ar

I've passed "-Wl,-baix5coff64-rs6000" in config. I've also set 
LDFLAGS="-Wl,-rpath=/usr/local/openssl/lib -Wl,-baix5coff64-rs6000" 
though I don't see how that would have an effect on this problem.

I get the same result when I try to run ar command shown in the make 
output from the command line:
 ??? ??? ar r ../test2.sh

where test2.sh contains all the *.o files in crypto

Every source I can find seems to indicate that gcc should just 'know' 
what the correct file format is. Am I missing something? Well, obviously 
I'm missing something. Can anyone point out what?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180417/a35d7e6c/attachment.html>

From rob.marshall17 at gmail.com  Tue Apr 17 21:34:13 2018
From: rob.marshall17 at gmail.com (Rob Marshall)
Date: Tue, 17 Apr 2018 17:34:13 -0400
Subject: [openssl-users] Applying security patches to 0.9.8a
Message-ID: <CALrmp7yqr0gk2rsUDvos3FuDtoKZfd8pXP11SAk+65_=ukThkg@mail.gmail.com>

Hi,

I have an application that runs on an old OS that currently has
OpenSSL 0.9.8a installed and many binaries dependent on
libssl.so.0.9.8. Would it be possible to get the recent (it looks like
0.9.8a is pretty old) security patches and apply them to create an
updated 0.9.8a?

Thanks,

Rob

From ludwig.mark at siemens.com  Tue Apr 17 21:47:23 2018
From: ludwig.mark at siemens.com (Ludwig, Mark)
Date: Tue, 17 Apr 2018 21:47:23 +0000
Subject: [openssl-users] ar : File format not recognized
In-Reply-To: <bfd227ef-4436-26c2-ac21-d67e3ec7d4c8@panix.com>
References: <bfd227ef-4436-26c2-ac21-d67e3ec7d4c8@panix.com>
Message-ID: <BC5672F8AD4C054BAF167C9801500D1A016B364557@USSLMMBX004.net.plm.eds.com>

> From: Bill Kurland, Tuesday, April 17, 2018 4:19 PM
> 
> I'm trying to build openssl-1.1.0h on AIX 6.1 with the ultimate goal of building the IO::Socket::SSL perl module.
> 
> make fails when creating libcrypto.a and libssl.a because, it seems, the *.o files are in a format not recognized by ar
> 
> I've passed "-Wl,-baix5coff64-rs6000" in config. I've also set LDFLAGS="-Wl,-rpath=/usr/local/openssl/lib -Wl,-baix5coff64-rs6000" though I don't see how that would have an effect on this problem.
> 
> I get the same result when I try to run ar command shown in the make output from the command line:
>         ar r ../test2.sh
> 
> where test2.sh contains all the *.o files in crypto
> 
> Every source I can find seems to indicate that gcc should just 'know' what the correct file format is. Am I missing something? Well, obviously I'm missing something. Can anyone point out what?
> 
> Thanks

Not sure this will help, because I built v1.0.2 (haven't gotten to v1.1.0 yet) using the AIX compiler rather than gcc, but the AIX archiver (ar) has a -X option that specifies how many bits.

For example, your example might work as:

         ar -X 64 r LIBNAME.a ../test2.sh

(At least, I assume you're building 64-bit binaries based on seeing "coff64" above.)
(I also assume you omitted the library name in e-mail.)

HTH,
Mark

From dclarke at blastwave.org  Tue Apr 17 21:58:30 2018
From: dclarke at blastwave.org (Dennis Clarke)
Date: Tue, 17 Apr 2018 17:58:30 -0400
Subject: [openssl-users] Applying security patches to 0.9.8a
In-Reply-To: <CALrmp7yqr0gk2rsUDvos3FuDtoKZfd8pXP11SAk+65_=ukThkg@mail.gmail.com>
References: <CALrmp7yqr0gk2rsUDvos3FuDtoKZfd8pXP11SAk+65_=ukThkg@mail.gmail.com>
Message-ID: <3210a7f6-9224-5848-7320-0da2063f79ec@blastwave.org>

On 17/04/18 05:34 PM, Rob Marshall wrote:
> Hi,
> 
> I have an application that runs on an old OS ...

I hate to be "that guy" and ask the dumb question but what OS is this
  and are you able to re-compile and re-link the application?


Dennis

From rsalz at akamai.com  Tue Apr 17 22:22:31 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 17 Apr 2018 22:22:31 +0000
Subject: [openssl-users] Applying security patches to 0.9.8a
In-Reply-To: <CALrmp7yqr0gk2rsUDvos3FuDtoKZfd8pXP11SAk+65_=ukThkg@mail.gmail.com>
References: <CALrmp7yqr0gk2rsUDvos3FuDtoKZfd8pXP11SAk+65_=ukThkg@mail.gmail.com>
Message-ID: <2FC2EEB8-ABE2-4F56-B5CB-17BAC07A7578@akamai.com>

>    I have an application that runs on an old OS that currently has
    OpenSSL 0.9.8a

So you should be able to compile and install the last 0.9.8 release, https://www.openssl.org/source/old/0.9.x/openssl-0.9.8zc.tar.gz  Note that this is more than two years old.  Many fixes have happened since then.
 
Good luck.


From rob.marshall17 at gmail.com  Tue Apr 17 22:36:09 2018
From: rob.marshall17 at gmail.com (Rob Marshall)
Date: Tue, 17 Apr 2018 18:36:09 -0400
Subject: [openssl-users] Applying security patches to 0.9.8a
In-Reply-To: <2FC2EEB8-ABE2-4F56-B5CB-17BAC07A7578@akamai.com>
References: <CALrmp7yqr0gk2rsUDvos3FuDtoKZfd8pXP11SAk+65_=ukThkg@mail.gmail.com>
 <2FC2EEB8-ABE2-4F56-B5CB-17BAC07A7578@akamai.com>
Message-ID: <CALrmp7wxKBw-EKTRad1UXK8PvM5aBqxaSSnZH2Lk1LSFVmC1Nw@mail.gmail.com>

Hi,

The OS is SLES 10 SP3 and there are currently close to 80 binaries
that appear to use libssl.so.0.9.8. They are from a bunch of different
packages, so I would imagine that updating to anything more recent
than 0.9.8 would be a major hassle and possibly not even possible.

I did find openssl-0.9.8zh.tar.gz which was last modified in 2015
which is way better than 0.9.8a which hasn't been touched since 2005.
I'm trying to install 0.9.8zh now to see if that works.

But I know someone is going to ask: Can you apply all of the newer
security fixes to 0.9.8zh? So I'll ask...can I?

Thanks,

Rob

On Tue, Apr 17, 2018 at 6:22 PM, Salz, Rich via openssl-users
<openssl-users at openssl.org> wrote:
>>    I have an application that runs on an old OS that currently has
>     OpenSSL 0.9.8a
>
> So you should be able to compile and install the last 0.9.8 release, https://www.openssl.org/source/old/0.9.x/openssl-0.9.8zc.tar.gz  Note that this is more than two years old.  Many fixes have happened since then.
>
> Good luck.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From matt at openssl.org  Tue Apr 17 22:50:52 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 17 Apr 2018 23:50:52 +0100
Subject: [openssl-users] Applying security patches to 0.9.8a
In-Reply-To: <CALrmp7wxKBw-EKTRad1UXK8PvM5aBqxaSSnZH2Lk1LSFVmC1Nw@mail.gmail.com>
References: <CALrmp7yqr0gk2rsUDvos3FuDtoKZfd8pXP11SAk+65_=ukThkg@mail.gmail.com>
 <2FC2EEB8-ABE2-4F56-B5CB-17BAC07A7578@akamai.com>
 <CALrmp7wxKBw-EKTRad1UXK8PvM5aBqxaSSnZH2Lk1LSFVmC1Nw@mail.gmail.com>
Message-ID: <9f9b5374-ff3e-726f-2f33-376acfc8cb44@openssl.org>



On 17/04/18 23:36, Rob Marshall wrote:
> Hi,
> 
> The OS is SLES 10 SP3 and there are currently close to 80 binaries
> that appear to use libssl.so.0.9.8. They are from a bunch of different
> packages, so I would imagine that updating to anything more recent
> than 0.9.8 would be a major hassle and possibly not even possible.
> 
> I did find openssl-0.9.8zh.tar.gz which was last modified in 2015
> which is way better than 0.9.8a which hasn't been touched since 2005.
> I'm trying to install 0.9.8zh now to see if that works.
> 
> But I know someone is going to ask: Can you apply all of the newer
> security fixes to 0.9.8zh? So I'll ask...can I?

Quick answer:

No

Longer answer:

You would have to analyse all of the security issues that have occurred
between the final release of 0.9.8 and the most up to date release of
1.0.2 (the oldest currently supported release). For each one you would
have to determine whether it is applicable to the 0.9.8 release and
then, if it is, backport it, which is likely to mean making a number of
changes to the patch. You're only going to be protected for that
security issue if you manage it without screwing up somewhere.

This is a *huge* amount of work. Do-able in theory. In practice - don't
bother.


Matt




> 
> Thanks,
> 
> Rob
> 
> On Tue, Apr 17, 2018 at 6:22 PM, Salz, Rich via openssl-users
> <openssl-users at openssl.org> wrote:
>>>    I have an application that runs on an old OS that currently has
>>     OpenSSL 0.9.8a
>>
>> So you should be able to compile and install the last 0.9.8 release, https://www.openssl.org/source/old/0.9.x/openssl-0.9.8zc.tar.gz  Note that this is more than two years old.  Many fixes have happened since then.
>>
>> Good luck.
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From dclarke at blastwave.org  Tue Apr 17 22:59:29 2018
From: dclarke at blastwave.org (Dennis Clarke)
Date: Tue, 17 Apr 2018 18:59:29 -0400
Subject: [openssl-users] Applying security patches to 0.9.8a
In-Reply-To: <CALrmp7wxKBw-EKTRad1UXK8PvM5aBqxaSSnZH2Lk1LSFVmC1Nw@mail.gmail.com>
References: <CALrmp7yqr0gk2rsUDvos3FuDtoKZfd8pXP11SAk+65_=ukThkg@mail.gmail.com>
 <2FC2EEB8-ABE2-4F56-B5CB-17BAC07A7578@akamai.com>
 <CALrmp7wxKBw-EKTRad1UXK8PvM5aBqxaSSnZH2Lk1LSFVmC1Nw@mail.gmail.com>
Message-ID: <4bfa02e3-420c-7b64-14da-3894d08b8b86@blastwave.org>

On 17/04/18 06:36 PM, Rob Marshall wrote:
> Hi,
> 
> The OS is SLES 10 SP3 and there are currently close to 80 binaries
> that appear to use libssl.so.0.9.8. They are from a bunch of different
> packages, so I would imagine that updating to anything more recent
> than 0.9.8 would be a major hassle and possibly not even possible.
> 
> I did find openssl-0.9.8zh.tar.gz which was last modified in 2015
> which is way better than 0.9.8a which hasn't been touched since 2005.
> I'm trying to install 0.9.8zh now to see if that works.
> 
> But I know someone is going to ask: Can you apply all of the newer
> security fixes to 0.9.8zh? So I'll ask...can I?
> 

The ABI is very stable.  You would do well to build the latest openssl
as Rich Salz says.  The dates on this page are a mess but you need the
latest :  https://www.openssl.org/source/old/0.9.x/

So build it into a user home directory like $HOME/local and then set
your LD_LIBRARY_PATH to point to that new lib dir and test your apps
against it.  There should be a major issue.

If all goes well, as it should, just build the libs into /usr/local/ssl
and test your apps again.

If that goes well ... you could backup your old libs and symlink in the
new ones you just built.

Just an idea.  Not perfect.

Dennis

From rsalz at akamai.com  Wed Apr 18 00:35:04 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 18 Apr 2018 00:35:04 +0000
Subject: [openssl-users] Applying security patches to 0.9.8a
In-Reply-To: <CALrmp7wxKBw-EKTRad1UXK8PvM5aBqxaSSnZH2Lk1LSFVmC1Nw@mail.gmail.com>
References: <CALrmp7yqr0gk2rsUDvos3FuDtoKZfd8pXP11SAk+65_=ukThkg@mail.gmail.com>
 <2FC2EEB8-ABE2-4F56-B5CB-17BAC07A7578@akamai.com>
 <CALrmp7wxKBw-EKTRad1UXK8PvM5aBqxaSSnZH2Lk1LSFVmC1Nw@mail.gmail.com>
Message-ID: <AB9A613B-AF25-4B63-8C6A-AB59AB9DCB03@akamai.com>

>    But I know someone is going to ask: Can you apply all of the newer
    security fixes to 0.9.8zh? So I'll ask...can I?
  
The project stopped supporting 0.9.8 2+ years ago, and announced its plans 3+ years ago.  Backporting fixes from 1.0.2 should be possible, but won't always be easy.

It might be worth contacting your vendor.



From bill at panix.com  Wed Apr 18 02:55:40 2018
From: bill at panix.com (Bill Kurland)
Date: Tue, 17 Apr 2018 22:55:40 -0400
Subject: [openssl-users] ar : File format not recognized
In-Reply-To: <BC5672F8AD4C054BAF167C9801500D1A016B364557@USSLMMBX004.net.plm.eds.com>
References: <bfd227ef-4436-26c2-ac21-d67e3ec7d4c8@panix.com>
 <BC5672F8AD4C054BAF167C9801500D1A016B364557@USSLMMBX004.net.plm.eds.com>
Message-ID: <b281c6d3-ddb9-5641-6c4b-2ff6589f44f0@panix.com>

On 4/17/2018 5:47 PM, Ludwig, Mark wrote:
>> From: Bill Kurland, Tuesday, April 17, 2018 4:19 PM
>>
>> I'm trying to build openssl-1.1.0h on AIX 6.1 with the ultimate goal of building the IO::Socket::SSL perl module.
>>
>> make fails when creating libcrypto.a and libssl.a because, it seems, the *.o files are in a format not recognized by ar
>>
>> I've passed "-Wl,-baix5coff64-rs6000" in config. I've also set LDFLAGS="-Wl,-rpath=/usr/local/openssl/lib -Wl,-baix5coff64-rs6000" though I don't see how that would have an effect on this problem.
>>
>> I get the same result when I try to run ar command shown in the make output from the command line:
>>          ar r ../test2.sh
>>
>> where test2.sh contains all the *.o files in crypto
>>
>> Every source I can find seems to indicate that gcc should just 'know' what the correct file format is. Am I missing something? Well, obviously I'm missing something. Can anyone point out what?
>>
>> Thanks
> Not sure this will help, because I built v1.0.2 (haven't gotten to v1.1.0 yet) using the AIX compiler rather than gcc, but the AIX archiver (ar) has a -X option that specifies how many bits.
>
> For example, your example might work as:
>
>           ar -X 64 r LIBNAME.a ../test2.sh
>
> (At least, I assume you're building 64-bit binaries based on seeing "coff64" above.)
> (I also assume you omitted the library name in e-mail.)
>
> HTH,
> Mark
You mean use the AIX ar on AIX? Who'd have thought? Not me. Did the trick.

Now on to the next error.

Thanks.

/b
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180417/65e169e1/attachment.html>

From mcepl at cepl.eu  Wed Apr 18 05:20:36 2018
From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl)
Date: Wed, 18 Apr 2018 07:20:36 +0200
Subject: [openssl-users] Applying security patches to 0.9.8a
References: <CALrmp7yqr0gk2rsUDvos3FuDtoKZfd8pXP11SAk+65_=ukThkg@mail.gmail.com>
 <2FC2EEB8-ABE2-4F56-B5CB-17BAC07A7578@akamai.com>
 <CALrmp7wxKBw-EKTRad1UXK8PvM5aBqxaSSnZH2Lk1LSFVmC1Nw@mail.gmail.com>
Message-ID: <slrnpddld4.1m8.mcepl@archaius.ceplovi.cz>

On 2018-04-17, 22:36 GMT, Rob Marshall wrote:
> The OS is SLES 10 SP3 and there are currently close to 80 
> binaries that appear to use libssl.so.0.9.8.

Whoever decided this platform is a good idea, was in my opinion 
wrong. https://en.wikipedia.org/wiki/SUSE_Linux_Enterprise tells 
me that a) there was SP4 ? why in the world you would not 
install that?, b) it was released April 2011, and all support of 
SLES 10 ceased on 2016-03-30.

Such system is either so disconnected from everything, that 
patching OpenSSL doesn't matter, or patching just OpenSSL (if it 
was possible at all) doesn't make much difference.

Mat?j
-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
You either die a hero or you live long enough to see yourself
become the villain.
  -- Harvey Dent in The Dark Knight


From vcizek at suse.com  Wed Apr 18 11:17:31 2018
From: vcizek at suse.com (Vitezslav Cizek)
Date: Wed, 18 Apr 2018 13:17:31 +0200
Subject: [openssl-users] Applying security patches to 0.9.8a
In-Reply-To: <CALrmp7wxKBw-EKTRad1UXK8PvM5aBqxaSSnZH2Lk1LSFVmC1Nw@mail.gmail.com>
References: <CALrmp7yqr0gk2rsUDvos3FuDtoKZfd8pXP11SAk+65_=ukThkg@mail.gmail.com>
 <2FC2EEB8-ABE2-4F56-B5CB-17BAC07A7578@akamai.com>
 <CALrmp7wxKBw-EKTRad1UXK8PvM5aBqxaSSnZH2Lk1LSFVmC1Nw@mail.gmail.com>
Message-ID: <20180418131731.2e3dc69a@kolac.suse.cz>

Hi,

On Tue, 17 Apr 2018 18:36:09 -0400
"Rob Marshall" <rob.marshall17 at gmail.com> wrote:

> The OS is SLES 10 SP3 and there are currently close to 80 binaries
> that appear to use libssl.so.0.9.8. They are from a bunch of different
> packages, so I would imagine that updating to anything more recent
> than 0.9.8 would be a major hassle and possibly not even possible.
> 
> I did find openssl-0.9.8zh.tar.gz which was last modified in 2015
> which is way better than 0.9.8a which hasn't been touched since 2005.
> I'm trying to install 0.9.8zh now to see if that works.
> 
> But I know someone is going to ask: Can you apply all of the newer
> security fixes to 0.9.8zh? So I'll ask...can I?

Of course you can.
But all the patches will fail to apply automatically, at least because
of the recent source code reformat. You'll have to do it by hand.

The good news is that most of the security vulnerabilities wouldn't
affect 0.9.8a. Many were introduced in the newer functionality, such as
elliptic curves, DTLS or new asm implementations.

Btw, SUSE is still maintaining SLE-10 (and backporting all the
security fixes) for some customers.
If you have access to the support channels, perhaps you can ask them.

-- 
V?t?zslav ???ek             Emergency Update Team (EMU)
"Whilst you sleep, we're probably saving the universe."

From rsalz at akamai.com  Wed Apr 18 15:28:41 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 18 Apr 2018 15:28:41 +0000
Subject: [openssl-users] What does this error mean?
In-Reply-To: <CALrmp7wDw23MB2UNVZonZWzQNMdr7B9kQqbcGuLxBE_QMCqomA@mail.gmail.com>
References: <CALrmp7xHdfwBCRzJDmbXvT=WMkwVjqgac+ZHkPyLD=esPasp2w@mail.gmail.com>
 <20180416183325.7g3foy35fdj5vezl@suse.de>
 <CALrmp7w0BhSdzm5m6f2jpC6ARspF9Du+t6fxES6-pQ7Cxuamdw@mail.gmail.com>
 <22722B4C-1B15-4C05-B587-C9963504D6D9@akamai.com>
 <CALrmp7wDw23MB2UNVZonZWzQNMdr7B9kQqbcGuLxBE_QMCqomA@mail.gmail.com>
Message-ID: <2B7C7F63-19A2-4E75-A348-CFE23361E3A8@akamai.com>

>    wget --no-check-certificate https://bootstrap.pypa.io/get-pip.py
  
When I try this:
	; ./apps/openssl s_client -connect bootstrap.pypa.io:443 -tls1_1
It fails.  When I leave off the last flag, it connects via TLS 1.2

So that website does not support anything older than TLS 1.2, apparently.  You'll have to build a modern OpenSSL, and then wget to use that version.  Good luck.



From nic.tuv at gmail.com  Thu Apr 19 17:46:39 2018
From: nic.tuv at gmail.com (Nicola)
Date: Thu, 19 Apr 2018 17:46:39 +0000
Subject: [openssl-users] Looking for beta testers for libsuola
Message-ID: <CANm5x_O911NY_B0=iE-iQ1E3AtfvLq5jgoL-V-s6GBFOZBPShA@mail.gmail.com>

Hey Folks,

we just released a project that we hope is going to help
researchers, developers, and ease the life of distro maintainers,
and of everyone working on making the Internet more secure through
OpenSSL, ultimately benefit all the users.

The project is called [libsuola](https://github.com/romen/libsuola)
and demonstrates how to use OpenSSL ENGINEs to provide
new/alternative cryptographic software implementations to OpenSSL
and, transparently, to existing applications linked against it.

The ultimate goal of our project is to provide users the freedom of
injecting alternative implementations or missing functionality in
OpenSSL, at runtime and transparently to existing applications.

The motivation for our project is illustrated in details in
[this paper][0], but just to mention some examples of what kind of
things libsuola could do in practice for users, I'll mention adding
support for X25519 or Ed25519 primitives for applications linked
against OpenSSL 1.0.2, or add Ed25519 to applications linked against
OpenSSL 1.1.0.
Moreover one can choose which implementation to use, selecting as a
backend provider:
-  [libsodium][1], which historically has a better record when it
comes to side-channel attack countermeasures and would also provide a
nice speed bump in performance; or
-  [HACL*][2], a formally verified fork of libsodium, coming with
strong mathematical assurance about functional correctness, memory
safety, and its side-channel attack countermeasures.

(For benchmarking geeks, numerophiles and everyone else interested,
nice and extensive tables collecting the timings we measured for
each operation, under different providers and on different
architectures are included in the paper!
Also, more details about a third kind of provider which statically
links crypto funcitonality internally rather than relying on an
external library.)


The other goal of the project is to propose a methodology for
researchers working on software implementations, to test and benchmark
their results in real-world scenarios and deliver them to a wider
audience.

Of course to achieve grand goals we need participation from the
community, so we are looking for beta testers to test the limits of
our project, gather ideas on how to extend it, spot its shortcomings
and get it under deeper scrutiny.


So please, if what you read felt at least mildly interesting, go to
https://github.com/romen/libsuola and check it out!


Our development and testing has so far been limited to Linux-based
environments and x64 / arm / arm64, but we welcome testers for other
architectures, and PRs for other dev chains.






TL;DR: Help us test a new way of adding functionality to your existing
OpenSSL-based applications. https://github.com/romen/libsuola






Thanks,

Nicola Tuveri
D.Sc. Student
NISEC group
Laboratory of Pervasive Computing
Tampere University of Technology, FINLAND




[0]: https://eprint.iacr.org/2018/354.pdf
[1]: https://github.com/jedisct1/libsodium
[2]: https://github.com/mitls/hacl-star

From swisniewski at salesforce.com  Fri Apr 20 02:45:41 2018
From: swisniewski at salesforce.com (Scott Wisniewski)
Date: Thu, 19 Apr 2018 19:45:41 -0700
Subject: [openssl-users] engine interface for genrsa
In-Reply-To: <CAFftDdrUQDyeauY+pxvRGUkFyXuFLJj-M_7PMjOzn9SMATuM-A@mail.gmail.com>
References: <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8+YQ@mail.gmail.com>
 <20180413.235555.817780897856405713.levitte@openssl.org>
 <CAFftDdrUQDyeauY+pxvRGUkFyXuFLJj-M_7PMjOzn9SMATuM-A@mail.gmail.com>
Message-ID: <CACsdVBDq-yaEEqy0=dxu4aOn0JgMc94gc85aM+YGCzXT84O=Jg@mail.gmail.com>

FYI:

If you provide an genrsa implementation in your engine that doesn't include
the private parameters, even if it's marked with RSA_FLAG_EXT_PKEY, the
openssl executable will not handle it correctly.

That's because genrsa_main assumes that the object that comes back is an
rsa private key. So it will attempt to save a PEM encoded RSA private key
even though it doesn't have the private key fields and openssl won't be
able to open the saved file.

So, if you want to enable use of the openssl executable with genrsa being
supported by your engine, you will actually need to modify apps/genrsa.c So
that genrsa_main does:

if (RSA_test_flags(rsa, RSA_FLAG_EXT_PKEY) == RSA_FLAG_EXT_PKEY) {

    if (! PEM_write_bio_RSA_PUBKEY(out, rsa))

        goto end;

}

else {

    if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,

                                     (pem_password_cb *)password_callback,

                                     &cb_data))

        goto end;

}

instead of:

if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,

                                    (pem_password_cb *)password_callback,

                                    &cb_data))

       goto end;

And then it will save the key you generated in public key pem format. which
will allow openssl to read it.

One thing to note:

None of the open source engines I checked (neither the PCKS11 engine, the
NCipher engine, nor the CAPI engine) implement the genrsa hook. If you are
looking for wide compatibility you may wish to ask your clients to do key
generation using an external utility (as that's how almost everyone else
does it).

On Fri, Apr 13, 2018 at 5:28 PM, William Roberts <bill.c.roberts at gmail.com>
wrote:

> On Fri, Apr 13, 2018 at 2:55 PM, Richard Levitte <levitte at openssl.org>
> wrote:
> > In message <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8
> +YQ at mail.gmail.com> on Fri, 13 Apr 2018 09:17:28 -0700, William Roberts <
> bill.c.roberts at gmail.com> said:
> >
> > bill.c.roberts> I am currently working on writing an openssl engine
> > bill.c.roberts> to interface with a piece of hardware.
> > bill.c.roberts>
> > bill.c.roberts> I am trying to understand how to implement
> > bill.c.roberts> rsa key generation, where the private key
> > bill.c.roberts> bytes would not be available.
> > bill.c.roberts>
> > bill.c.roberts> I am currently invoking the
> > bill.c.roberts> command:
> > bill.c.roberts>
> > bill.c.roberts> openssl genrsa -engine foo
> > bill.c.roberts>
> > bill.c.roberts> Which is calling my callback for RSA keygen, registered
> via ENGINE_set_RSA()
> > bill.c.roberts> and I set the flags: RSA_FLAG_EXT_PKEY.
> > bill.c.roberts>
> > bill.c.roberts> However, genrsa app seems to want rsa->e set here:
> > bill.c.roberts> https://github.com/openssl/openssl/blob/OpenSSL_1_0_2g/
> apps/genrsa.c#L291
> > bill.c.roberts>
> > bill.c.roberts> I can't find documentation on how to handle the keygen
> interface
> > bill.c.roberts> for RSA.
> > bill.c.roberts>
> > bill.c.roberts> Can someone point me in the right direction?
> >
> > e and n are public components of any RSA key pair (and RSA structure
> > in OpenSSL).  You *must* make them available.  The rest of the numbers
> > are private and do not need to be part of the RSA structure that
> > OpenSSL handles.
>
> Thanks. I went and read the RSA page on Wikipedia, and sure enough it
> has what common meanings of what all the single letter variables
> are in the RSA struct.
> https://en.wikipedia.org/wiki/RSA_(cryptosystem)
>
> >
> > Cheers,
> > Richard
> >
> > --
> > Richard Levitte         levitte at openssl.org
> > OpenSSL Project         http://www.openssl.org/~levitte/
> > --
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180419/b04c7c14/attachment.html>

From garycjohnso at gmail.com  Fri Apr 20 03:26:34 2018
From: garycjohnso at gmail.com (Gary Johnson)
Date: Thu, 19 Apr 2018 23:26:34 -0400
Subject: [openssl-users] Pre-TLS Handshake Data
Message-ID: <CAAvqB-PBq_wEK+jj=T0HyWa8OTbcOj54ntfzs9btj5groMXjyg@mail.gmail.com>

Hey Folks,

I'm trying to figure out what this data is that is being sent pre-handshake:

$ openssl s_client -connect google.com:443 -debug -state -msg
CONNECTED(00000005)
SSL_connect:before/connect initialization
write to 0x7ff53bc07c20 [0x7ff53c002e00] (318 bytes => 318 (0x13E))
0000 - 16 03 01 01 39 01 00 01-35 03 03 3e d2 76 71 98   ....9...5..>.vq.
0010 - 9a 32 40 29 cf 4a ad 40-86 12 61 1b 44 97 3f 35   .2@).J. at ..a.D.?5
0020 - e2 fd 43 83 d2 4d 6a 18-32 30 0d 00 00 98 cc 14   ..C..Mj.20......
0030 - cc 13 cc 15 c0 30 c0 2c-c0 28 c0 24 c0 14 c0 0a   .....0.,.(.$....
0040 - 00 a3 00 9f 00 6b 00 6a-00 39 00 38 ff 85 00 c4   .....k.j.9.8....
0050 - 00 c3 00 88 00 87 00 81-c0 32 c0 2e c0 2a c0 26   .........2...*.&
0060 - c0 0f c0 05 00 9d 00 3d-00 35 00 c0 00 84 c0 2f   .......=.5...../
0070 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67   .+.'.#.........g
0080 - 00 40 00 33 00 32 00 be-00 bd 00 45 00 44 c0 31   . at .3.2.....E.D.1
0090 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f   .-.).%.......<./
00a0 - 00 ba 00 41 c0 11 c0 07-c0 0c c0 02 00 05 00 04   ...A............
00b0 - c0 12 c0 08 00 16 00 13-c0 0d c0 03 00 0a 00 15   ................
00c0 - 00 12 00 09 00 ff 01 00-00 74 00 0b 00 04 03 00   .........t......
00d0 - 01 02 00 0a 00 3a 00 38-00 0e 00 0d 00 19 00 1c   .....:.8........
00e0 - 00 0b 00 0c 00 1b 00 18-00 09 00 0a 00 1a 00 16   ................
00f0 - 00 17 00 08 00 06 00 07-00 14 00 15 00 04 00 05   ................
0100 - 00 12 00 13 00 01 00 02-00 03 00 0f 00 10 00 11   ................
0110 - 00 23 00 00 00 0d 00 26-00 24 06 01 06 02 06 03   .#.....&.$......
0120 - ef ef 05 01 05 02 05 03-04 01 04 02 04 03 ee ee   ................
0130 - ed ed 03 01 03 02 03 03-02 01 02 02 02 03         ..............

I've looked through the github code repo but nothing stands out to me.
Although I do noticed those first 11 bytes seem to repeat no matter what
domain I call.
Any help or guidance in the right direction as to the answer would be
appreciated. Thanks.

-- 
Gary Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180419/cef60ac0/attachment.html>

From matt at openssl.org  Fri Apr 20 08:20:49 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 20 Apr 2018 09:20:49 +0100
Subject: [openssl-users] Pre-TLS Handshake Data
In-Reply-To: <CAAvqB-PBq_wEK+jj=T0HyWa8OTbcOj54ntfzs9btj5groMXjyg@mail.gmail.com>
References: <CAAvqB-PBq_wEK+jj=T0HyWa8OTbcOj54ntfzs9btj5groMXjyg@mail.gmail.com>
Message-ID: <0508146e-ac32-6e9a-b7dc-d24fb6108931@openssl.org>



On 20/04/18 04:26, Gary Johnson wrote:
> Hey Folks,
> 
> I'm trying to figure out what this data is that is being sent pre-handshake:
> 
> $ openssl s_client -connect google.com:443 <http://google.com:443>
> -debug -state -msg
> CONNECTED(00000005)
> SSL_connect:before/connect initialization
> write to 0x7ff53bc07c20 [0x7ff53c002e00] (318 bytes => 318 (0x13E))
> 0000 - 16

This indicates SSL/TLS record is a handshake packet

> 03 01

The record has version TLSv1.0

> 01 39

The record has this length

> 01

Now we start the body of the message contained inside the record. This
indicates this is a ClientHello message

> 00 01-35

This is the length of the message

> 03 03

The maximum supported TLS version this client is willing to negotiate is
TLSv1.2

> 3e d2 76 71 98? ?....9...5..>.vq.
> 0010 - 9a 32 40 29 cf 4a ad 40-86 12 61 1b 44 97 3f 35? ?.2@).J. at ..a.D.?5
> 0020 - e2 fd 43 83 d2 4d 6a 18-32 30 0d

This is the client random value


> 00

There is no session id

> 00 98

This is the length of the list of available ciphersuites.

The remaining data is the list of ciphersuites, any compression methods
and extensions that are present.

See RFC5246 section7.4.1.2

Matt

> cc 14? ?..C..Mj.20......
> 0030 - cc 13 cc 15 c0 30 c0 2c-c0 28 c0 24 c0 14 c0 0a? ?.....0.,.(.$....
> 0040 - 00 a3 00 9f 00 6b 00 6a-00 39 00 38 ff 85 00 c4? ?.....k.j.9.8....
> 0050 - 00 c3 00 88 00 87 00 81-c0 32 c0 2e c0 2a c0 26? ?.........2...*.&
> 0060 - c0 0f c0 05 00 9d 00 3d-00 35 00 c0 00 84 c0 2f? ?.......=.5...../
> 0070 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67? ?.+.'.#.........g
> 0080 - 00 40 00 33 00 32 00 be-00 bd 00 45 00 44 c0 31? ?. at .3.2.....E.D.1
> 0090 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f? ?.-.).%.......<./
> 00a0 - 00 ba 00 41 c0 11 c0 07-c0 0c c0 02 00 05 00 04? ?...A............
> 00b0 - c0 12 c0 08 00 16 00 13-c0 0d c0 03 00 0a 00 15   ...............
> 00c0 - 00 12 00 09 00 ff 01 00-00 74 00 0b 00 04 03 00? ?.........t......
> 00d0 - 01 02 00 0a 00 3a 00 38-00 0e 00 0d 00 19 00 1c? ?.....:.8........
> 00e0 - 00 0b 00 0c 00 1b 00 18-00 09 00 0a 00 1a 00 16? ?................
> 00f0 - 00 17 00 08 00 06 00 07-00 14 00 15 00 04 00 05? ?................
> 0100 - 00 12 00 13 00 01 00 02-00 03 00 0f 00 10 00 11? ?................
> 0110 - 00 23 00 00 00 0d 00 26-00 24 06 01 06 02 06 03? ?.#.....&.$......
> 0120 - ef ef 05 01 05 02 05 03-04 01 04 02 04 03 ee ee? ?................
> 0130 - ed ed 03 01 03 02 03 03-02 01 02 02 02 03? ? ? ? ?..............
> 
> I've looked through the github code repo but nothing stands out to me.
> Although I do noticed those first 11 bytes seem to repeat no matter what
> domain I call.
> Any help or guidance in the right direction as to the answer would be
> appreciated. Thanks.
> 
> -- 
> Gary Johnson
> 
> 

From curt at strategix.se  Fri Apr 20 08:32:51 2018
From: curt at strategix.se (Curt Johansson)
Date: Fri, 20 Apr 2018 10:32:51 +0200
Subject: [openssl-users] Pre-TLS Handshake Data
In-Reply-To: <CAAvqB-PBq_wEK+jj=T0HyWa8OTbcOj54ntfzs9btj5groMXjyg@mail.gmail.com>
References: <CAAvqB-PBq_wEK+jj=T0HyWa8OTbcOj54ntfzs9btj5groMXjyg@mail.gmail.com>
Message-ID: <58415238-D8E5-410D-BBCA-2285A250FC82@strategix.se>

This is a client hello message in the TLS protocol sent from the client. Full spec is found on https://www.ietf.org/rfc/rfc5246.txt and
I suggest using Wireshark to analyze network traffic but basically your message is described by  



16 		Content type (handshake) 
03 01 	TLS version (1.0)
01 39 	Length of message

The rest is the Handshake message

01 		Client Hello message
00 01 35  Message length
03 03 	Client requested TLS version (1.2)
3e .. 71	Unix time GMT (4 bytes)
98 ...  0d	Random (28 bytes)
00		Session id length (no session id) 
00 98	Length of cipher suite list the client accepts (76 cipher suites) 
cc 14	First ciphersuite - ECDHE-ECDSA-CHACHA20-POLY1305
..
00 ff 	Last cipher suite - TLS_EMPTY_RENEGOTIATION_INFO_SCSV actually not a "real" cipher suite but a flag to signal client is ready to handle renegotiation
01		Number of compression methods
00 		Compression method (no compression) 
00 74	Extensions length
00 0b 00 04 03 00 01 02 First extension (ec_point_format) 

following by others. 


Hope this help you get started. 

Curt

> On 20 Apr 2018, at 5:26 , Gary Johnson <garycjohnso at gmail.com> wrote:
> 
> Hey Folks,
> 
> I'm trying to figure out what this data is that is being sent pre-handshake:
> 
> $ openssl s_client -connect google.com:443 -debug -state -msg
> CONNECTED(00000005)
> SSL_connect:before/connect initialization
> write to 0x7ff53bc07c20 [0x7ff53c002e00] (318 bytes => 318 (0x13E))
> 0000 - 16 03 01 01 39 01 00 01-35 03 03 3e d2 76 71 98   ....9...5..>.vq.
> 0010 - 9a 32 40 29 cf 4a ad 40-86 12 61 1b 44 97 3f 35   .2@).J. at ..a.D.?5
> 0020 - e2 fd 43 83 d2 4d 6a 18-32 30 0d 00 00 98 cc 14   ..C..Mj.20......
> 0030 - cc 13 cc 15 c0 30 c0 2c-c0 28 c0 24 c0 14 c0 0a   .....0.,.(.$....
> 0040 - 00 a3 00 9f 00 6b 00 6a-00 39 00 38 ff 85 00 c4   .....k.j.9.8....
> 0050 - 00 c3 00 88 00 87 00 81-c0 32 c0 2e c0 2a c0 26   .........2...*.&
> 0060 - c0 0f c0 05 00 9d 00 3d-00 35 00 c0 00 84 c0 2f   .......=.5...../
> 0070 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67   .+.'.#.........g
> 0080 - 00 40 00 33 00 32 00 be-00 bd 00 45 00 44 c0 31   . at .3.2.....E.D.1
> 0090 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f   .-.).%.......<./
> 00a0 - 00 ba 00 41 c0 11 c0 07-c0 0c c0 02 00 05 00 04   ...A............
> 00b0 - c0 12 c0 08 00 16 00 13-c0 0d c0 03 00 0a 00 15   ................
> 00c0 - 00 12 00 09 00 ff 01 00-00 74 00 0b 00 04 03 00   .........t......
> 00d0 - 01 02 00 0a 00 3a 00 38-00 0e 00 0d 00 19 00 1c   .....:.8........
> 00e0 - 00 0b 00 0c 00 1b 00 18-00 09 00 0a 00 1a 00 16   ................
> 00f0 - 00 17 00 08 00 06 00 07-00 14 00 15 00 04 00 05   ................
> 0100 - 00 12 00 13 00 01 00 02-00 03 00 0f 00 10 00 11   ................
> 0110 - 00 23 00 00 00 0d 00 26-00 24 06 01 06 02 06 03   .#.....&.$......
> 0120 - ef ef 05 01 05 02 05 03-04 01 04 02 04 03 ee ee   ................
> 0130 - ed ed 03 01 03 02 03 03-02 01 02 02 02 03         ..............
> 
> I've looked through the github code repo but nothing stands out to me. Although I do noticed those first 11 bytes seem to repeat no matter what domain I call.
> Any help or guidance in the right direction as to the answer would be appreciated. Thanks.
> 
> -- 
> Gary Johnson
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From afenkart at gmail.com  Mon Apr 23 13:43:01 2018
From: afenkart at gmail.com (Andreas Fenkart)
Date: Mon, 23 Apr 2018 15:43:01 +0200
Subject: [openssl-users] gpgsm/cms: int_rsa_verify:wrong signature length
Message-ID: <CALtMJED5-Nrj5yh4R4235FNhP=bOwm5CvFdx7HyTLVeE49JFJQ@mail.gmail.com>

Hi,

I am using GnuPG to sign 'swupdate' update images, that are verified on the
target using openssl:

  gpgsm -o sw-description.sig -sb sw-description

swupdate links against the openssl, but the equivalent cmd line is:

  openssl cms -verify -in sw-description.sig -inform DER -content
sw-description \
                -CAfile mycert.cert.pem -binary

This works for quite a while with no problem, just suddenly I see this error
when verifying

  140250102395072:error:04091077:rsa routines:int_rsa_verify:wrong
signature length:../crypto/rsa/rsa_sign.c:132:
  140250102395072:error:2E09809E:CMS
routines:CMS_SignerInfo_verify:verification
failure:../crypto/cms/cms_sd.c:738:

gpgsm verfication though works.

Comparing the asn1parse output of working/non-working signatures, I can see
that the non-working signature is 1-byte longer then the working version

$ diff /tmp/works /tmp/broken
76,77c76,77
<   929:d=3  hl=4 l= 561 cons: SET
<   933:d=4  hl=4 l= 557 cons: SEQUENCE
---
>   929:d=3  hl=4 l= 559 cons: SET
>   933:d=4  hl=4 l= 555 cons: SEQUENCE
105c105
<  1234:d=5  hl=4 l= 256 prim: OCTET STRING      [HEX
DUMP]:EF4378D3F5AFDE79974518722EA1B12F7DE7C71239B03676378A9B2AC7F5BB76AF91DFE05B004AA0C68CAD8CE54021C61CD49943BA513888D29A6B5AD41942FC57BCBFE1A1B68607EC875434119A28DC6C3463CE4C9B0C948E89C93CB18B7FFDBCDAB6467501E15CD5B603CAA8693DBF27B70B624F15E2BE0A1BD02EB26E619D2EC6A8A939BAB6CA169ABB6A0A76319AD9208728AE566312B63281D03B77B0A38A46FB63FFF5741D4484B14CBF46D092B42D3878AA333CA6CDF6A2412B4DA4DB2AD2DE401506D9B7C24B6CEC18160BC1CBF30426217C27C4CCFDB3B444BBE9C2C9A95D12925A77FA6E6795DE4FFE223C943F15823BC642483F0244A7551052AE
<  1494:d=3  hl=2 l=   0 prim: EOC
<  1496:d=2  hl=2 l=   0 prim: EOC
<  1498:d=1  hl=2 l=   0 prim: EOC
---
>  1234:d=5  hl=3 l= 255 prim: OCTET STRING      [HEX DUMP]:AE0DAC25E87228FF787FD632BC056BC26601E5077537435AD5F653F52B1D13C5194E1B2E35DBD09C059EE55092575CBB7F9AD5B23F5599CC7009BB494FD96CD2C1D4CD5BC0EE674713ADCA41322BCEF25EC1EDB25EAE308E668E30298C88660917775AA76CCF1E60FA8941181B6F1E7D96600A8B9116ABFDDA7A3AFB4D17B15CC8B761EDE09D6E3B6A257B2F1E129A1BE1F192B8E684B872ACA72BDEC7F482D568ABF482EBB97F5A24D0D14281AD8AF169204A395071C96BF2F4BB780EBD3ABD640D373CA8F0EB7AE46CA37E8A8D5E2DB575354DF79F46E004B700E0FC50F06AD8670FD6855B62B7F1279C2A0640794485A824760ED681C4BF9E2742A0698D
>  1492:d=3  hl=2 l=   0 prim: EOC
>  1494:d=2  hl=2 l=   0 prim: EOC
>  1496:d=1  hl=2 l=   0 prim: EOC


This is my gpgsm version, I did not upgrade to the latest version yet

  $ gpgsm --version
  gpgsm (GnuPG) 2.1.7-unknown
  libgcrypt 1.6.3
  libksba 1.3.3-unknown
  Copyright (C) 2015 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.


Any idea?

kind regards,
Andi

From bill.c.roberts at gmail.com  Mon Apr 23 16:58:10 2018
From: bill.c.roberts at gmail.com (William Roberts)
Date: Mon, 23 Apr 2018 09:58:10 -0700
Subject: [openssl-users] engine interface for genrsa
In-Reply-To: <CACsdVBDq-yaEEqy0=dxu4aOn0JgMc94gc85aM+YGCzXT84O=Jg@mail.gmail.com>
References: <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8+YQ@mail.gmail.com>
 <20180413.235555.817780897856405713.levitte@openssl.org>
 <CAFftDdrUQDyeauY+pxvRGUkFyXuFLJj-M_7PMjOzn9SMATuM-A@mail.gmail.com>
 <CACsdVBDq-yaEEqy0=dxu4aOn0JgMc94gc85aM+YGCzXT84O=Jg@mail.gmail.com>
Message-ID: <CAFftDdp5BZh3yt4n0tTvMv4hRbVxBJ+qB6OyNq53nf0PnQQXLw@mail.gmail.com>

On Thu, Apr 19, 2018 at 7:45 PM, Scott Wisniewski
<swisniewski at salesforce.com> wrote:
> FYI:
>
> If you provide an genrsa implementation in your engine that doesn't include
> the private parameters, even if it's marked with RSA_FLAG_EXT_PKEY, the
> openssl executable will not handle it correctly.
>
> That's because genrsa_main assumes that the object that comes back is an rsa
> private key. So it will attempt to save a PEM encoded RSA private key even
> though it doesn't have the private key fields and openssl won't be able to
> open the saved file.
>
> So, if you want to enable use of the openssl executable with genrsa being
> supported by your engine, you will actually need to modify apps/genrsa.c So
> that genrsa_main does:
>
> if (RSA_test_flags(rsa, RSA_FLAG_EXT_PKEY) == RSA_FLAG_EXT_PKEY) {
>
>     if (! PEM_write_bio_RSA_PUBKEY(out, rsa))
>
>         goto end;
>
> }
>
> else {
>
>     if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,
>
>                                      (pem_password_cb *)password_callback,
>
>                                      &cb_data))
>
>         goto end;
>
> }
>
>
> instead of:
>
> if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,
>
>                                     (pem_password_cb *)password_callback,
>
>                                     &cb_data))
>
>        goto end;
>
>
> And then it will save the key you generated in public key pem format. which
> will allow openssl to read it.

Good to know, thanks for the detail.

>
> One thing to note:
>
> None of the open source engines I checked (neither the PCKS11 engine, the
> NCipher engine, nor the CAPI engine) implement the genrsa hook. If you are
> looking for wide compatibility you may wish to ask your clients to do key
> generation using an external utility (as that's how almost everyone else
> does it).

I have only looked at the PKCS11 module, and it's quite limited in
functionality.
I've been extending it submitting patches as they make sense. I just added
random support.


>
> On Fri, Apr 13, 2018 at 5:28 PM, William Roberts <bill.c.roberts at gmail.com>
> wrote:
>>
>> On Fri, Apr 13, 2018 at 2:55 PM, Richard Levitte <levitte at openssl.org>
>> wrote:
>> > In message
>> > <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8+YQ at mail.gmail.com> on Fri,
>> > 13 Apr 2018 09:17:28 -0700, William Roberts <bill.c.roberts at gmail.com> said:
>> >
>> > bill.c.roberts> I am currently working on writing an openssl engine
>> > bill.c.roberts> to interface with a piece of hardware.
>> > bill.c.roberts>
>> > bill.c.roberts> I am trying to understand how to implement
>> > bill.c.roberts> rsa key generation, where the private key
>> > bill.c.roberts> bytes would not be available.
>> > bill.c.roberts>
>> > bill.c.roberts> I am currently invoking the
>> > bill.c.roberts> command:
>> > bill.c.roberts>
>> > bill.c.roberts> openssl genrsa -engine foo
>> > bill.c.roberts>
>> > bill.c.roberts> Which is calling my callback for RSA keygen, registered
>> > via ENGINE_set_RSA()
>> > bill.c.roberts> and I set the flags: RSA_FLAG_EXT_PKEY.
>> > bill.c.roberts>
>> > bill.c.roberts> However, genrsa app seems to want rsa->e set here:
>> > bill.c.roberts>
>> > https://github.com/openssl/openssl/blob/OpenSSL_1_0_2g/apps/genrsa.c#L291
>> > bill.c.roberts>
>> > bill.c.roberts> I can't find documentation on how to handle the keygen
>> > interface
>> > bill.c.roberts> for RSA.
>> > bill.c.roberts>
>> > bill.c.roberts> Can someone point me in the right direction?
>> >
>> > e and n are public components of any RSA key pair (and RSA structure
>> > in OpenSSL).  You *must* make them available.  The rest of the numbers
>> > are private and do not need to be part of the RSA structure that
>> > OpenSSL handles.
>>
>> Thanks. I went and read the RSA page on Wikipedia, and sure enough it
>> has what common meanings of what all the single letter variables
>> are in the RSA struct.
>> https://en.wikipedia.org/wiki/RSA_(cryptosystem)
>>
>> >
>> > Cheers,
>> > Richard
>> >
>> > --
>> > Richard Levitte         levitte at openssl.org
>> > OpenSSL Project         http://www.openssl.org/~levitte/
>> > --
>> > 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 mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

From rsalz at akamai.com  Mon Apr 23 23:44:24 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 23 Apr 2018 23:44:24 +0000
Subject: [openssl-users] gpgsm/cms: int_rsa_verify:wrong signature length
In-Reply-To: <CALtMJED5-Nrj5yh4R4235FNhP=bOwm5CvFdx7HyTLVeE49JFJQ@mail.gmail.com>
References: <CALtMJED5-Nrj5yh4R4235FNhP=bOwm5CvFdx7HyTLVeE49JFJQ@mail.gmail.com>
Message-ID: <9A1F8F39-AF71-45A1-ABB2-2DDE6427DC8A@akamai.com>

Your key starts with EF...  Since that has the high-bit on, it should be encoded with a leading zero.

 


From openssl-users at dukhovni.org  Tue Apr 24 00:47:54 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 23 Apr 2018 20:47:54 -0400
Subject: [openssl-users] gpgsm/cms: int_rsa_verify:wrong signature length
In-Reply-To: <9A1F8F39-AF71-45A1-ABB2-2DDE6427DC8A@akamai.com>
References: <CALtMJED5-Nrj5yh4R4235FNhP=bOwm5CvFdx7HyTLVeE49JFJQ@mail.gmail.com>
 <9A1F8F39-AF71-45A1-ABB2-2DDE6427DC8A@akamai.com>
Message-ID: <DC51F4C2-F079-427A-A135-AFF37B822B5E@dukhovni.org>



> On Apr 23, 2018, at 7:44 PM, Salz, Rich via openssl-users <openssl-users at openssl.org> wrote:
> 
> Your key starts with EF...  Since that has the high-bit on, it should be encoded with a leading zero.

Are you sure?  That does not look like a key to me...

More likely to be the signature block.  The broken one
is one byte shorter, and perhaps the issue is that the
RSA encrypted data has a leading byte that happens to
be zero (1 chance in ~<256 depending on high bytes of
modulus), and this got left out. Hence:

 int_rsa_verify:wrong signature length:../crypto/rsa/rsa_sign.c:132:

The code in question is:

   if (siglen != (size_t)RSA_size(rsa)) {
       RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_WRONG_SIGNATURE_LENGTH);
       return 0;
   }

which clearly shows that signature lengths are expected to be
exactly the same size as the modulus (padded with leading zeros
as needed).

Note that per:

   https://tools.ietf.org/html/rfc8017#section-8.2.1

the signature length MUST be the same as the modulus length.
A 256-byte modulus goes with a 2048-bit key.

-- 
	Viktor.

From rsalz at akamai.com  Tue Apr 24 01:35:13 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 24 Apr 2018 01:35:13 +0000
Subject: [openssl-users] gpgsm/cms: int_rsa_verify:wrong signature length
In-Reply-To: <DC51F4C2-F079-427A-A135-AFF37B822B5E@dukhovni.org>
References: <CALtMJED5-Nrj5yh4R4235FNhP=bOwm5CvFdx7HyTLVeE49JFJQ@mail.gmail.com>
 <9A1F8F39-AF71-45A1-ABB2-2DDE6427DC8A@akamai.com>
 <DC51F4C2-F079-427A-A135-AFF37B822B5E@dukhovni.org>
Message-ID: <E3C03D09-2057-4060-9697-69EE3A99C5ED@akamai.com>

Yeah, you're probably right.  I was distracted, should have  looked closer.
 


From asharpele at gmail.com  Tue Apr 24 02:54:09 2018
From: asharpele at gmail.com (ojike asharpel)
Date: Tue, 24 Apr 2018 03:54:09 +0100
Subject: [openssl-users] engine interface for genrsa
In-Reply-To: <CAJJd=gaEsV8yD7ZsxWOxvoMC-urOAUePxYO46xJg0+f7uf2O4A@mail.gmail.com>
References: <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8+YQ@mail.gmail.com>
 <20180413.235555.817780897856405713.levitte@openssl.org>
 <CAFftDdrUQDyeauY+pxvRGUkFyXuFLJj-M_7PMjOzn9SMATuM-A@mail.gmail.com>
 <CACsdVBDq-yaEEqy0=dxu4aOn0JgMc94gc85aM+YGCzXT84O=Jg@mail.gmail.com>
 <CAJJd=gZL0XZG_emdzh9CHnvZwhfBmQGwOWJCEwHd3tfLuR8PFA@mail.gmail.com>
 <CAJJd=gaEsV8yD7ZsxWOxvoMC-urOAUePxYO46xJg0+f7uf2O4A@mail.gmail.com>
Message-ID: <CAJJd=gYTdrb70b53t1PtLB1Oe0ujQ8XqV1+A3Nejo9+dQk=vHQ@mail.gmail.com>

Hello dear,
I joined these group so that l can get assistance for my research work.
Up till now, l have not been able.

Here is my problem.

My Project is an Msc Research on HTTPS Man-In-The-Middle (MITM) Attack
using a Compromised Certificate Authority.
Now I am going to be very elaborative so that you can read my mind and
understand what I want to achieve.
I have a Journal base paper am already working on. The author designed a
new HTTPAS (HTTP Active Secure) ? These are the major work he did on his
project. He designed a HTTPAS framework that will enhance Client-Server web
Authentication and make the web authentication more comprehensive incase a
MITM attacker has compromised one or few Certificate Authorities.
Note: The MITM attacker has different vantage point and different attacking
patterns. For the
man-in-the-middle variant ?, the vantage point is close to the victim web
user (e.g. a gateway or a wireless access point of the victim user is
compromised by man-in-the-middle attackers), and
the attackers can blindly hijack all the HTTPS connections from the victim
user to any remote web sites (i.e. the attacking pattern is non-selective
hijacking).
Another Variant 2 takes the case that the vantage point is nearby web
servers. This variant is harder to detect than the others, because nearly
all the Internet paths to the victim web server necessarily pass through
the vantage point.
Look at his designs

He designed a client-side countermeasure which enables a web user to
actively collect site certificates from n different web sites. A
man-in-the-middle attack can be confirmed if these n certificates are
issued from less than ? CAs. (This countermeasure is based on a key insight
that a large number of site certificates from different Internet domains
are unlikely issued by the same CA, only if a man-in-the?middle variant is
launched with a single compromised CA.)
He also designed another Client-side countermeasure by enabling web users
to actively collect site certificates from other web servers of the same
web site. The key insight of this countermeasure is that popular web sites
usually deploy a large distributed system of servers across the Internet to
serve end users from different regions for high availability and
performance (i.e. content delivery network or CDN in short). These web
servers are likely to use the certificates issued from the same CA, while
the man-in-the-middle vantage point near one web server is unlikely to be
close to others, especially the ones located in a different geographical
region.
Concerning his implementations, please read very well?. ?We evaluate these
performance overheads

by implementing a prototype of HTTPAS using OpenSSL stacks. Our HTTPAS
prototype runs additional certificate collection and verification tasks in
a parallel manner. We achieve this parallel solution by exploiting the C++
multi-threading programming. We conduct the performance evaluation by
running our HTTPAS prototype implementation in a virtual machine and a real
machine, both of which are located in our laboratory with 8-core 2.67 GHz
central processing unit and 6 GB memory. We use the virtual machine for
HTTPAS performance evaluation due to a very practical reason: lots of
modern web sites are now hosted by cloud computing environments, where
virtual machines are the web servers running behind.



Dear friends, l need help, even though,it might require some financial
involvement.  I all respect that. I want to replicate this work and also
improve it

On Apr 20, 2018 3:46 AM, "Scott Wisniewski" <swisniewski at salesforce.com>
wrote:

> FYI:
>
> If you provide an genrsa implementation in your engine that doesn't
> include the private parameters, even if it's marked with RSA_FLAG_EXT_PKEY,
> the openssl executable will not handle it correctly.
>
> That's because genrsa_main assumes that the object that comes back is an
> rsa private key. So it will attempt to save a PEM encoded RSA private key
> even though it doesn't have the private key fields and openssl won't be
> able to open the saved file.
>
> So, if you want to enable use of the openssl executable with genrsa being
> supported by your engine, you will actually need to modify apps/genrsa.c So
> that genrsa_main does:
>
> if (RSA_test_flags(rsa, RSA_FLAG_EXT_PKEY) == RSA_FLAG_EXT_PKEY) {
>
>     if (! PEM_write_bio_RSA_PUBKEY(out, rsa))
>
>         goto end;
>
> }
>
> else {
>
>     if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,
>
>                                      (pem_password_cb *)password_callback,
>
>                                      &cb_data))
>
>         goto end;
>
> }
>
> instead of:
>
> if (!PEM_write_bio_RSAPrivateKey(out, rsa, enc, NULL, 0,
>
>                                     (pem_password_cb *)password_callback,
>
>                                     &cb_data))
>
>        goto end;
>
> And then it will save the key you generated in public key pem format.
> which will allow openssl to read it.
>
> One thing to note:
>
> None of the open source engines I checked (neither the PCKS11 engine, the
> NCipher engine, nor the CAPI engine) implement the genrsa hook. If you are
> looking for wide compatibility you may wish to ask your clients to do key
> generation using an external utility (as that's how almost everyone else
> does it).
>
> On Fri, Apr 13, 2018 at 5:28 PM, William Roberts <bill.c.roberts at gmail.com
> > wrote:
>
>> On Fri, Apr 13, 2018 at 2:55 PM, Richard Levitte <levitte at openssl.org>
>> wrote:
>> > In message <CAFftDdqWPXq1+Mo9_6J0EzhZ4uwg5QC=R5fx8N1j=QYchA8+YQ at mail.gm
>> ail.com> on Fri, 13 Apr 2018 09:17:28 -0700, William Roberts <
>> bill.c.roberts at gmail.com> said:
>> >
>> > bill.c.roberts> I am currently working on writing an openssl engine
>> > bill.c.roberts> to interface with a piece of hardware.
>> > bill.c.roberts>
>> > bill.c.roberts> I am trying to understand how to implement
>> > bill.c.roberts> rsa key generation, where the private key
>> > bill.c.roberts> bytes would not be available.
>> > bill.c.roberts>
>> > bill.c.roberts> I am currently invoking the
>> > bill.c.roberts> command:
>> > bill.c.roberts>
>> > bill.c.roberts> openssl genrsa -engine foo
>> > bill.c.roberts>
>> > bill.c.roberts> Which is calling my callback for RSA keygen, registered
>> via ENGINE_set_RSA()
>> > bill.c.roberts> and I set the flags: RSA_FLAG_EXT_PKEY.
>> > bill.c.roberts>
>> > bill.c.roberts> However, genrsa app seems to want rsa->e set here:
>> > bill.c.roberts> https://github.com/openssl/ope
>> nssl/blob/OpenSSL_1_0_2g/apps/genrsa.c#L291
>> > bill.c.roberts>
>> > bill.c.roberts> I can't find documentation on how to handle the keygen
>> interface
>> > bill.c.roberts> for RSA.
>> > bill.c.roberts>
>> > bill.c.roberts> Can someone point me in the right direction?
>> >
>> > e and n are public components of any RSA key pair (and RSA structure
>> > in OpenSSL).  You *must* make them available.  The rest of the numbers
>> > are private and do not need to be part of the RSA structure that
>> > OpenSSL handles.
>>
>> Thanks. I went and read the RSA page on Wikipedia, and sure enough it
>> has what common meanings of what all the single letter variables
>> are in the RSA struct.
>> https://en.wikipedia.org/wiki/RSA_(cryptosystem)
>>
>> >
>> > Cheers,
>> > Richard
>> >
>> > --
>> > Richard Levitte         levitte at openssl.org
>> > OpenSSL Project         http://www.openssl.org/~levitte/
>> > --
>> > 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 mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180424/3affd4dd/attachment.html>

From Michael.Wojcik at microfocus.com  Tue Apr 24 13:11:59 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 24 Apr 2018 13:11:59 +0000
Subject: [openssl-users] HTTPAS (was RE:  engine interface for genrsa)
Message-ID: <SN1PR18MB2112575BFC4B4FFA6230EB81F9880@SN1PR18MB2112.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of ojike asharpel
> Sent: Monday, April 23, 2018 22:54

> I joined these group so that l can get assistance for my research work.

Fine. However, don't hijack an existing discussion for a new topic. That's considered impolite, and it makes it difficult for readers to follow the discussion. Post a fresh message to the list with an appropriate subject line.

> My Project is an Msc Research on HTTPS Man-In-The-Middle (MITM) Attack using a Compromised
> Certificate Authority.
...
> I have a Journal base paper am already working on. The author designed a new HTTPAS (HTTP Active Secure) ?

Right. So you're working from a paper that appears to describe a couple of statistical heuristics on certificate issuance which might be used, with some probability, to detect MITM attacks made using entity certificates generated by a compromised CA.

First, I'll note that I'm not sure how valuable this original contribution (as I understand it) is, in the current era of Certificate Transparency - which is, after all, already displacing pinning (HPKP) as a countermeasure, because it's superior (at least in its failure modes). While the public X.509 PKI is a horrible mess, it's less horrible than it was even a few years ago. Is there any great need for heuristic countermeasures, particularly when end-user confusion is already one of our biggest problems?

Second: After reading your paraphrase of the HTTPAS project, I still don't know what *your* project is. You've identified this paper that describes an experimental protocol. What do you want to do with it?

> Dear friends, l need help, even though,it might require some financial involvement.

This makes me nervous. Financial compensation for assistance with a graduate research project? In the US, that would almost certainly be considered unethical (except when compensating research subjects under terms approved by an IRB, which doesn't seem to be the situation here). Asking questions is one thing; paid assistance is quite another.

I hope this is helpful.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From mcepl at cepl.eu  Wed Apr 25 08:09:48 2018
From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl)
Date: Wed, 25 Apr 2018 10:09:48 +0200
Subject: [openssl-users] [ANN] M2Crypto 0.29.0 ... now supporting Windows
Message-ID: <1524643788.9436.1.camel@cepl.eu>

Hi, everybody,

this is just a bugfix release. Marcus Huewe stepped up and
produced a lot of smaller bugfixes while working on
https://gitlab.com/m2crypto/m2crypto/merge_requests/188 (which
itself has not been finished yet for this release).

Also, we finally got rid off some remaining old-style?classes
(that's pre-2.2).

Also, we no longer support Python 2.6 on Windows (it is still
supported on Linux), hopefully people there are able to upgrade
to 2.7.

Also, reminder, that we have special email list for development
of M2Crypto. Its web page is http://redcrew.org/mailman/listinfo/
m2crypto and it is mailman with the posting address
m2crypto at lists.redcrew.org so all email commands work.

All complaints, support requests, and bug reports are welcome in
the email list or on the issue tracker
https://gitlab.com/m2crypto/m2crypto/issues

Happy security hacking!

Mat?j

-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled.
    -- R. P. Feynman's concluding sentence
       in his appendix to the Challenger Report
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180425/92d1ddea/attachment.sig>

From szagoruyko at mutualink.net  Wed Apr 25 16:26:57 2018
From: szagoruyko at mutualink.net (Sergey Zagoruyko)
Date: Wed, 25 Apr 2018 11:26:57 -0500
Subject: [openssl-users] build OpenSSL for iOS with -fembed-bitcode
Message-ID: <1B83DC95-9B10-4AC6-B76B-420E2FC17B13@mutualink.net>

Hello,

I?m trying to build OpenSSL 1.1.0f for iOS with bitcode enabled, using -fembed-bitcode flag. I got an error: 

ld: -bundle and -bitcode_bundle (Xcode setting ENABLE_BITCODE=YES) cannot be used together

In the Makefile.shared I found string: SHAREDFLAGS="$(CFLAGS) `echo $(SHARED_LDFLAGS) | sed s/dynamiclib/bundle/`"; \

Is that causing the conflict? How can I fix it and build with bitcode enabled?



Have a good day

Sergey Zagoruyko

iOS Developer
Mutualink, Inc.

Toll Free: (866) 957-5465 Ext: 507
E-Mail: szagoruyko at mutualink.net 

Web: www.mutualink.net

Certified by the Department of Homeland Security SAFETY Act for Interoperable Communications

The information in this email, and subsequent attachments, may contain confidential information that is intended solely for the attention and use of the named addressee(s). This message or any part thereof must not be disclosed, copied, distributed or retained by any person without authorization from the addressee.

Visit Mutualink at the following social media sites:

Facebook: www.facebook.com/Mutualink
LinkedIn: www.linkedin.com/company/Mutualink
Twitter: www.twitter.com/MutualinkInc





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180425/1d7a5110/attachment.html>

From kgoldman at us.ibm.com  Wed Apr 25 16:58:49 2018
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Wed, 25 Apr 2018 12:58:49 -0400
Subject: [openssl-users] X509 certificate algorithm
In-Reply-To: <20120816133307.GA67093@openssl.org>
References: <OFD9A76BB3.14FF669E-ON85257A5C.0047AD01-85257A5C.004872AB@us.ibm.com>
 <20120816133307.GA67093@openssl.org>
Message-ID: <pbqc06$3g0$1@blaine.gmane.org>

On 08/16/12 09:33, Dr. Stephen Henson wrote:
> On Thu, Aug 16, 2012, Kenneth Goldman wrote:
> 
>> I call these:
>>
>> d2i_X509()
>> X509_print_fp()
>>
>> which calls
>>          pkey_set_type()
>>                  EVP_PKEY_asn1_find()
>> and that call fails.
>>
>> I've traced the following error down to the rsaOAEP algorithm, which has a
>> nid of 919.  I've included both the openssl and dumpasn1 dump of the
>> X509 certificate.  Am I doing something wrong in openssl, or is there
>> a problem with the certificate?  I tried certificates from two
>> vendors, and they both fail at the same point.
>>
>>
> 
> Well the problem is that OpenSSL doesn't currently support OAEP certificates.
> I've never come across one so if you could send an example that would be
> useful.

I'm back working with these certificates and find that it still fails 
with the latest openssl.

Another user has apparently hit the same issue.

https://github.com/openssl/openssl/pull/1441

Is there any chance of rsaOAEP being supported?

These are TPM 1.2 endorsement key certificates and there are 
(unfortunately) 100M's of them shipped.


From nospam001-lists at jan-kohnert.de  Thu Apr 26 08:46:17 2018
From: nospam001-lists at jan-kohnert.de (Jan Kohnert)
Date: Thu, 26 Apr 2018 10:46:17 +0200
Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to
 1.1.0
In-Reply-To: <4d98fc4078cc1b18d96d975cfaa218ff@jan-kohnert.de>
References: <dd5454066cf21088eb7d67617cec8578@jan-kohnert.de>
 <20180323192532.21d09104@jan-kohnert.de>
 <BN6PR1701MB185996E234FE33385561F184CCA80@BN6PR1701MB1859.namprd17.prod.outlook.com>
 <20180327190153.6900f554@jan-kohnert.de>
 <BN6PR1701MB185929A0B68FAF986195A356CCAC0@BN6PR1701MB1859.namprd17.prod.outlook.com>
 <20180328004033.719feef8@jan-kohnert.de>
 <4d98fc4078cc1b18d96d975cfaa218ff@jan-kohnert.de>
Message-ID: <c19643acb4eac91f5e0aff42e26ca957@jan-kohnert.de>

Am 2018-03-29 09:07, schrieb Jan Kohnert:
> Next update after clean test on another Win32 maschine: there have to
> be crypt32.lib and ws2_32.lib libs linked, besides that the code is
> unchanged. As the code produces correct asn1 files on Linux (see
> previous mail), it now looks even more like a bug in the
> crypto-library on Windows...
> 
> Following output:

[...]

> C:\Users\Alkes\Downloads\TestCrypt\build>openssl smime -decrypt -inform
> DER -in
> testfile.crypt -inkey local.key -out testfile.sig
> 
> C:\Users\Alkes\Downloads\TestCrypt\build>openssl smime -verify -inform
> DER -in t
> estfile.sig -CAfile local.cert
> Error reading S/MIME message

Damnit! Problem exists between keyboard and chair. Command should have 
been:
openssl smime -verify -inform DER -in t estfile.sig -binary -CAfile 
local.cert
                                                     ^^^^^^^
It was the decrypting messing up the asn1-structure on Win when not 
using the
binary option (-outform DER whould have worked, too).

So the code works in Win and Linux. :) Thread closed.

-- 
Best regards Jan

From dheinz at softwarekey.com  Thu Apr 26 12:50:57 2018
From: dheinz at softwarekey.com (Dan Heinz)
Date: Thu, 26 Apr 2018 12:50:57 +0000
Subject: [openssl-users] Manual Shutdown of OpenSSL 1.1.x  library
Message-ID: <CY1PR0601MB1577AB4700CCE0E83E952703D98E0@CY1PR0601MB1577.namprd06.prod.outlook.com>

We have not moved from OpenSSL 1.0.x to OpenSSL 1.1.x as we require the ability to manually shutdown the library.  We noticed in the latest release notes the following:
"Modify compression code so it frees up structures without using the ex_data callbacks. This works around a problem where some applications call CRYPTO_cleanup_all_ex_data() before application exit (e.g. when restarting) then use compression (e.g. SSL with compression) later. This results in significant per-connection memory leaks and has caused some security issues including CVE-2008-1678 and CVE-2009-4355".

Is there now a way to manually shutdown the library?

To summarize: We have a DLL that statically links OpenSSL.  Our DLL gets loaded and unloaded multiple times by a process (not our process), and we need to release OpenSSL each time.  This was not possible with OpenSSL 1.1 as of September 2017 as the process's atexit is where it gets released which will not be called after a FreeLibrary() call on our DLL.  Has this been revisited?  If there now a way to manually release OpenSSL, or are there any plans to add this ability?

>From the previous post, something like this would address the issue: "I'm wondering whether an option to override the default behavior might be possible, e.g. an explicit call to OPENSSL_init_crypto() with something like an OPENSSL_INIT_NO_ATEXIT_CLEANUP option. The application would then have to call OPENSSL_cleanup() explicitly."
Original issue posted with discussion:
https://www.mail-archive.com/openssl-users at openssl.org/msg80781.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180426/18565236/attachment-0001.html>

From kgoldman at us.ibm.com  Thu Apr 26 20:17:53 2018
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Thu, 26 Apr 2018 16:17:53 -0400
Subject: [openssl-users] Get raw RSA public key from X509 certificate
Message-ID: <pbtc1g$1b0$1@blaine.gmane.org>

I have to get the raw public modulus, but I cannot X509_get_pubkey() 
because of a non-standard object identifier.

I can use X509_get_X509_PUBKEY() to get part way there.  I see the DER 
wrapped key in the public_key.data element, but I don't know an API to 
get to that element.

Am I on the right track, or is there a better way?

Could some very kind person give me the code flow?




From matt at openssl.org  Thu Apr 26 20:37:03 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 26 Apr 2018 21:37:03 +0100
Subject: [openssl-users] Get raw RSA public key from X509 certificate
In-Reply-To: <pbtc1g$1b0$1@blaine.gmane.org>
References: <pbtc1g$1b0$1@blaine.gmane.org>
Message-ID: <44cb8b39-9b59-f35d-6294-e838db1533ab@openssl.org>



On 26/04/18 21:17, Ken Goldman wrote:
> I have to get the raw public modulus, but I cannot X509_get_pubkey()
> because of a non-standard object identifier.
> 
> I can use X509_get_X509_PUBKEY() to get part way there.? I see the DER
> wrapped key in the public_key.data element, but I don't know an API to
> get to that element.

How about X509_PUBKEY_get0_param():

https://www.openssl.org/docs/man1.1.0/crypto/X509_PUBKEY_get0_param.html

Matt


> 
> Am I on the right track, or is there a better way?
> 
> Could some very kind person give me the code flow?
> 
> 
> 

From kgoldman at us.ibm.com  Thu Apr 26 22:48:18 2018
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Thu, 26 Apr 2018 18:48:18 -0400
Subject: [openssl-users] Get raw RSA public key from X509 certificate
In-Reply-To: <44cb8b39-9b59-f35d-6294-e838db1533ab@openssl.org>
References: <pbtc1g$1b0$1@blaine.gmane.org>
 <44cb8b39-9b59-f35d-6294-e838db1533ab@openssl.org>
Message-ID: <pbtkrf$1l9$1@blaine.gmane.org>

On 04/26/18 16:37, Matt Caswell wrote:
> 
> 
> On 26/04/18 21:17, Ken Goldman wrote:
>> I have to get the raw public modulus, but I cannot X509_get_pubkey()
>> because of a non-standard object identifier.
>>
>> I can use X509_get_X509_PUBKEY() to get part way there.? I see the DER
>> wrapped key in the public_key.data element, but I don't know an API to
>> get to that element.
> 
> How about X509_PUBKEY_get0_param():
> 
> https://www.openssl.org/docs/man1.1.0/crypto/X509_PUBKEY_get0_param.html
> 

Thanks!  That got me halfway there.

That gives me a DER steam that is a SEQUENCE of two INTEGERs.  The first 
is the public modulus and the second one is the exponent.

How do I go from that SEQUENCE to the components, and then from the 
components to their byte streams and lengths?

I assume it's some raw DER function like d2i_something.


From matt at openssl.org  Fri Apr 27 08:50:39 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 27 Apr 2018 09:50:39 +0100
Subject: [openssl-users] Get raw RSA public key from X509 certificate
In-Reply-To: <pbtkrf$1l9$1@blaine.gmane.org>
References: <pbtc1g$1b0$1@blaine.gmane.org>
 <44cb8b39-9b59-f35d-6294-e838db1533ab@openssl.org>
 <pbtkrf$1l9$1@blaine.gmane.org>
Message-ID: <c5eea91a-dcb8-142d-efdf-365dd8ce0a80@openssl.org>



On 26/04/18 23:48, Ken Goldman wrote:
> On 04/26/18 16:37, Matt Caswell wrote:
>>
>>
>> On 26/04/18 21:17, Ken Goldman wrote:
>>> I have to get the raw public modulus, but I cannot X509_get_pubkey()
>>> because of a non-standard object identifier.
>>>
>>> I can use X509_get_X509_PUBKEY() to get part way there.? I see the DER
>>> wrapped key in the public_key.data element, but I don't know an API to
>>> get to that element.
>>
>> How about X509_PUBKEY_get0_param():
>>
>> https://www.openssl.org/docs/man1.1.0/crypto/X509_PUBKEY_get0_param.html
>>
> 
> Thanks!? That got me halfway there.
> 
> That gives me a DER steam that is a SEQUENCE of two INTEGERs.? The first
> is the public modulus and the second one is the exponent.
> 
> How do I go from that SEQUENCE to the components, and then from the
> components to their byte streams and lengths?
> 
> I assume it's some raw DER function like d2i_something.
> 

How about create a mem-bio backed by the buffer containing the raw data
and then call d2i_RSAPublicKey_bio()?

Matt


From kgoldman at us.ibm.com  Fri Apr 27 14:01:19 2018
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 27 Apr 2018 10:01:19 -0400
Subject: [openssl-users] Get raw RSA public key from X509 certificate
In-Reply-To: <c5eea91a-dcb8-142d-efdf-365dd8ce0a80@openssl.org>
References: <pbtc1g$1b0$1@blaine.gmane.org>
 <44cb8b39-9b59-f35d-6294-e838db1533ab@openssl.org>
 <pbtkrf$1l9$1@blaine.gmane.org>
 <c5eea91a-dcb8-142d-efdf-365dd8ce0a80@openssl.org>
Message-ID: <442a7013-2911-b4fb-178a-606cf489ca17@us.ibm.com>

On 04/27/18 04:50, Matt Caswell wrote:
> 
> 
> On 26/04/18 23:48, Ken Goldman wrote:
>> On 04/26/18 16:37, Matt Caswell wrote:
>>>
>>>
>>> On 26/04/18 21:17, Ken Goldman wrote:
>>>> I have to get the raw public modulus, but I cannot X509_get_pubkey()
>>>> because of a non-standard object identifier.
>>>>
>>>> I can use X509_get_X509_PUBKEY() to get part way there.? I see the DER
>>>> wrapped key in the public_key.data element, but I don't know an API to
>>>> get to that element.
>>>
>>> How about X509_PUBKEY_get0_param():
>>>
>>> https://www.openssl.org/docs/man1.1.0/crypto/X509_PUBKEY_get0_param.html
>>>
>>
>> Thanks!? That got me halfway there.
>>
>> That gives me a DER steam that is a SEQUENCE of two INTEGERs.? The first
>> is the public modulus and the second one is the exponent.
>>
>> How do I go from that SEQUENCE to the components, and then from the
>> components to their byte streams and lengths?
>>
>> I assume it's some raw DER function like d2i_something.
>>
> 
> How about create a mem-bio backed by the buffer containing the raw data
> and then call d2i_RSAPublicKey_bio()?

That was it!  What threw me off is that the documentation says:

	 TYPE *d2i_TYPE(TYPE **a, unsigned char **ppin, long length);

but RSAPublicKey isn't a type.  So the pattern of TYPE being a structure 
name didn't hold.

(There is  a d2i_RSAPublicKey() function, so I didn't need the BIO.)

For the record. here's the resulting set of calls:

X509 * = d2i_X509()
X509_PUBKEY * = X509_get_X509_PUBKEY()
X509_PUBKEY_get0_param()
RSA * = d2i_RSAPublicKey()
~~~~
RSA_get0_key()
BN_bn2bin()

For a more standard certificate, the first 4 calls can be replaced by:

X509 * = d2i_X509()
EVP_PKEY * = X509_get_pubkey();
RSA * = EVP_PKEY_get1_RSA()



From matt at openssl.org  Fri Apr 27 14:16:19 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 27 Apr 2018 15:16:19 +0100
Subject: [openssl-users] Get raw RSA public key from X509 certificate
In-Reply-To: <442a7013-2911-b4fb-178a-606cf489ca17@us.ibm.com>
References: <pbtc1g$1b0$1@blaine.gmane.org>
 <44cb8b39-9b59-f35d-6294-e838db1533ab@openssl.org>
 <pbtkrf$1l9$1@blaine.gmane.org>
 <c5eea91a-dcb8-142d-efdf-365dd8ce0a80@openssl.org>
 <442a7013-2911-b4fb-178a-606cf489ca17@us.ibm.com>
Message-ID: <f8cc3116-7c20-d4d6-b0ba-4569efeb6acf@openssl.org>



On 27/04/18 15:01, Ken Goldman wrote:
> That was it!? What threw me off is that the documentation says:
> 
> ???? TYPE *d2i_TYPE(TYPE **a, unsigned char **ppin, long length);
> 
> but RSAPublicKey isn't a type.? So the pattern of TYPE being a structure
> name didn't hold.

Ahh. Interesting. In most places where we have a d2i function the name
of the function and the type is the same thing. This is one place where
it isn't.


> 
> (There is? a d2i_RSAPublicKey() function, so I didn't need the BIO.)

Duh...of course.

Matt


From simon.edwards301 at gmail.com  Fri Apr 27 16:29:09 2018
From: simon.edwards301 at gmail.com (Simon Edwards)
Date: Fri, 27 Apr 2018 17:29:09 +0100
Subject: [openssl-users] Why is CARoot handling different in Servers
 verifying Clients versus Clients verifying Servers? Is Server verifying
 Clients broken in dual-cert-type installations?
Message-ID: <CAEq1Smaa1zcV0TXG81BL3jxOCJSUDxLWWNAf-5f=GTWGs8dMCg@mail.gmail.com>

Hello,

Its been about 12 years since my last post here. So I apologize in advance
if I trample anyone/anything due to any changes in etiquette since back
then.


I wonder of anyone can shed light on why OpenSSL treats the two CARoot file
collections used in Servers and Clients differently?

Is it simply for performance purposes?


The reason I ask is that I have found a difference in behaviour between the
two implementations, which on the surface at least looks like a bug - or at
least a missed piece of implementation. It has had an unwanted effect in my
testing setup.


This issue concerns the handling of multiple types of CARoot and
Intermediate Certs held in a single PEM file.

I'm using 1.0.2 for debugging, but the following code is also in 1.1.0 and
1.1.1.


All of the following takes place in ssl/ssl_certs.c.


For Clients the CARoot collection's cert store generator works as follows:

    *SSL_CTX_load_verify_locations*() calls *X509_load_cert_crl_file*()  to
load a file into a ctx based store.

In my test case all 6 CARoot and Intermediate certs are loaded.


The Server's side however takes a completely different route to do a very
similar task. It also stores the results in a different place.

    *SSL_load_client_CA_file*()  is the Server's CARoot cert collection
generator

This *SSL_load_client_CA_file*() checks each new cert being loaded against
hashes of existing Subject_Name entries of certificates already loaded into
the stack of certs and discards duplicates.

   This check is done using *X509_get_subject_name*() and the comparison is
done using *sk_X509_NAME_find*()

In my test case only 5 of the 6 certs are loaded. I think this is wrong.



The same CARoot collection PEM file is being used in both cases.


My problem is triggered because I am testing a dual RSA/ECDSA
implementation on a single Server endpoint, and I also have ECDSA and RSA
identified clients.

All the certs involved are generated for the test scenario using OpenSSL.
Not commercial certs.

    4 levels of intermediate RSA certs.
    The RSA CARoot cert
    The ECDSA CARoot cert


Servers and Clients are generated at various levels of the intermediate
collection. Plus directly by the ECDSA CAroot.



The issue is that all unidentified/un-certified Clients can connect to
Servers, but Servers will reject some certified Clients when asked to
verify them.

Depending upon the order of the content in the CARoots PEM file the
rejected Clients will change.

The problem is that the CARoot cert is available in both signature types -
but the rest of the identification information in the two certificates is
pretty much the same content. The time stamps change of course, but its
identifying the same CA. Just using different signature types.

Because of the Server side test of the SubjectName, the subject name of
whichever cert is second in the PEM file will be compared with the
previously loaded certificate and ignored. This preventing Clients
identified by that CA from being verified.

This looks like a bug in OpenSSL based upon the assumption that the
SubjectName hash is enough of a unique identifier. Which was probably true
back when all certs were RSA certs. Nothing else needed checking.

Surely a more accurate approach today would be to combine the SubjectName
with the certificate signature type when creating the hash values.  Or to
simply do what the client side does and avoid duplication checks - now I do
know that the latter is not a sensible action for performance reasons.



BTW I realize that simply changing the ID to "CA Name RSA" and CA Name
ECDSA" would most likely solve this for my test case. However I don't think
I should need to do this. Or is this a miss-understanding on my part?

I'm also aware of this which may have introduced the issue:

http://openssl.6102.n7.nabble.com/openssl-org-3495-Enhance-SSL-load-client-CA-file-td52977.html


Am I missing something fundamental here?

Is the Server side verification supposed to work for multiple signature
types when they are identifying the same CARoot entities?

If so, I suggest that the sig' type not being checked alongside the
SubjectName when checking for duplicates is a bug.


Simon Edwards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180427/0971cde5/attachment-0001.html>

From kurt at roeckx.be  Sun Apr 29 10:43:26 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 29 Apr 2018 12:43:26 +0200
Subject: [openssl-users] Call for testing TLS 1.3
Message-ID: <20180429104326.GA21314@roeckx.be>

The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
1.3 brings a lot of changes that might cause incompatibility. For
an overview see https://wiki.openssl.org/index.php/TLS1.3

We are considering if we should enable TLS 1.3 by default or not,
or when it should be enabled. For that, we would like to know how
applications behave with the latest beta release.

When testing this, it's important that both sides of the
connection support the same TLS 1.3 draft version. OpenSSL
currently implements draft 26. We would like to see tests
for OpenSSL acting as client and server.

https://github.com/tlswg/tls13-spec/wiki/Implementations lists
other TLS 1.3 implementations and the draft they currently
support. Note that the versions listed there might not be for the
latest release. It also lists some https test servers.

We would really like to see a diverse set of applictions being
tested. Please report any results you have to us.


Kurt


From morthalaanilreddy at gmail.com  Sun Apr 29 13:14:33 2018
From: morthalaanilreddy at gmail.com (Anil kumar Reddy)
Date: Sun, 29 Apr 2018 15:14:33 +0200
Subject: [openssl-users] Posting a question
Message-ID: <CAPvigM+f9ASzjcj4==32r6uV7HVRRE=u7EwQVfuwMDpMMt8mMA@mail.gmail.com>

Hello,


I have posted my question into the forum. Please kindly approve it as soon
as possible.

Thanking you,

BR,
Anil Kumar Reddy Morthala
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180429/155d4d51/attachment.html>

From rsalz at akamai.com  Sun Apr 29 16:44:34 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 29 Apr 2018 16:44:34 +0000
Subject: [openssl-users] Posting a question
In-Reply-To: <CAPvigM+f9ASzjcj4==32r6uV7HVRRE=u7EwQVfuwMDpMMt8mMA@mail.gmail.com>
References: <CAPvigM+f9ASzjcj4==32r6uV7HVRRE=u7EwQVfuwMDpMMt8mMA@mail.gmail.com>
Message-ID: <958C7448-6786-4C6E-B52E-A39F5424B73D@akamai.com>

  *   I have posted my question into the forum. Please kindly approve it as soon as possible.

Which forum?

The fact that you were able to post to the openssl-users mailing list means you should just post your question, well, to the openssl-users mailing list. ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180429/ef175fcd/attachment.html>

From dclarke at blastwave.org  Mon Apr 30 02:05:39 2018
From: dclarke at blastwave.org (Dennis Clarke)
Date: Sun, 29 Apr 2018 22:05:39 -0400
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <20180429104326.GA21314@roeckx.be>
References: <20180429104326.GA21314@roeckx.be>
Message-ID: <cb243983-462e-c68d-b9b9-ed48453a954a@blastwave.org>

On 29/04/18 06:43 AM, Kurt Roeckx wrote:
> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> 1.3 brings a lot of changes that might cause incompatibility. For
> an overview see https://wiki.openssl.org/index.php/TLS1.3

Looking at https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites
there are five pure TLSv1.3 ciphersuites listed. At the moment the
OpenSSL 1.1.1-pre5 utters :

n0$ LD_LIBRARY_PATH=`pwd` apps/openssl ciphers -v | grep " TLSv1\.3 "
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
n0$

So using a client connect test to apache means build up a separate
instance ( and toolchain perhaps ) running with pre4 beta only and a
self cert and then ... isolate to only TLS_AES_256_GCM_SHA384 ( for
example ) in the apache ssl config. This will take some days just for
an initial test framework and then try :

n0$ LD_LIBRARY_PATH=`pwd` apps/openssl s_client -connect 
www.tls13.net:443 -tls1_3
CONNECTED(00000004)
4294967296:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure:ssl/record/rec_layer_s3.c:1569:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 239 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
     Protocol  : TLSv1.3
     Cipher    : 0000
     Session-ID:
     Session-ID-ctx:
     Master-Key:
     PSK identity: None
     PSK identity hint: None
     SRP username: None
     Start Time: 1525051962
     Timeout   : 7200 (sec)
     Verify return code: 0 (ok)
     Extended master secret: no
---
n0$

This should be fun to test.

> https://github.com/tlswg/tls13-spec/wiki/Implementations lists
> other TLS 1.3 implementations and the draft they currently
> support. Note that the versions listed there might not be for the
> latest release. It also lists some https test servers.

I'll take a look.

Dennis

From simon.edwards301 at gmail.com  Mon Apr 30 09:24:08 2018
From: simon.edwards301 at gmail.com (Simon Edwards)
Date: Mon, 30 Apr 2018 10:24:08 +0100
Subject: [openssl-users] Posting a question
In-Reply-To: <958C7448-6786-4C6E-B52E-A39F5424B73D@akamai.com>
References: <CAPvigM+f9ASzjcj4==32r6uV7HVRRE=u7EwQVfuwMDpMMt8mMA@mail.gmail.com>
 <958C7448-6786-4C6E-B52E-A39F5424B73D@akamai.com>
Message-ID: <CAEq1SmaVieqbPJsZR6XWWhxwuuVhULCMMzh3osEWsEyebTDzyQ@mail.gmail.com>

That's odd. I've been waiting for a post that I sent on Friday to appear.
Nothing so far.

The list seems to be far more active now than on Friday.

On Sun, Apr 29, 2018 at 5:44 PM, Salz, Rich via openssl-users <
openssl-users at openssl.org> wrote:

>
>    - I have posted my question into the forum. Please kindly approve it
>    as soon as possible.
>
>
>
> Which forum?
>
>
>
> The fact that you were able to post to the openssl-users mailing list
> means you should just post your question, well, to the openssl-users
> mailing list. ?
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180430/8e190641/attachment-0001.html>

From kurt at roeckx.be  Mon Apr 30 09:46:45 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 30 Apr 2018 11:46:45 +0200
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <cb243983-462e-c68d-b9b9-ed48453a954a@blastwave.org>
References: <20180429104326.GA21314@roeckx.be>
 <cb243983-462e-c68d-b9b9-ed48453a954a@blastwave.org>
Message-ID: <20180430094645.GA15982@roeckx.be>

On Sun, Apr 29, 2018 at 10:05:39PM -0400, Dennis Clarke wrote:
> On 29/04/18 06:43 AM, Kurt Roeckx wrote:
> > The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> > 1.3 brings a lot of changes that might cause incompatibility. For
> > an overview see https://wiki.openssl.org/index.php/TLS1.3
> 
> Looking at https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites
> there are five pure TLSv1.3 ciphersuites listed. At the moment the
> OpenSSL 1.1.1-pre5 utters :
> 
> n0$ LD_LIBRARY_PATH=`pwd` apps/openssl ciphers -v | grep " TLSv1\.3 "
> TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
> n0$

Yes, by default only 3 are anbled, but there are also 2 other
supported included in ALL.

> So using a client connect test to apache means build up a separate
> instance ( and toolchain perhaps ) running with pre4 beta only and a
> self cert and then ... isolate to only TLS_AES_256_GCM_SHA384 ( for
> example ) in the apache ssl config. This will take some days just for
> an initial test framework and then try :

Note that Apache requires a patch that was commited 4 weeks ago to
support TLS 1.3. It just seems to make TLS 1.3 known to the
configuration files and things like that, I'm not sure why that was
needed in the first place.


Kurt


From noreply81 at t-online.de  Mon Apr 30 13:42:11 2018
From: noreply81 at t-online.de (81)
Date: Mon, 30 Apr 2018 15:42:11 +0200
Subject: [openssl-users] (no subject)
Message-ID: <1fD94G-18cong0@fwd37.t-online.de>



Gesendet von Mail f?r Windows 10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180430/61f7a0e7/attachment.html>

From dclarke at blastwave.org  Mon Apr 30 15:48:20 2018
From: dclarke at blastwave.org (Dennis Clarke)
Date: Mon, 30 Apr 2018 11:48:20 -0400
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <20180430094645.GA15982@roeckx.be>
References: <20180429104326.GA21314@roeckx.be>
 <cb243983-462e-c68d-b9b9-ed48453a954a@blastwave.org>
 <20180430094645.GA15982@roeckx.be>
Message-ID: <eca64ede-d3f8-de11-47ca-e9db90723fe6@blastwave.org>


> Yes, by default only 3 are anbled, but there are also 2 other
> supported included in ALL.

I must have done something wrong here as I see these 3 only :


n0$ LD_LIBRARY_PATH=`pwd`/openssl-1.1.1-pre5_SunOS5.10_sparc64vii+.001 \
 > openssl-1.1.1-pre5_SunOS5.10_sparc64vii+.001/apps/openssl \
 > ciphers -V -s -tls1_3 | \
 > awk '{printf("%8s  %10s  %30s  %12s  %10s  %28s  %s\n", $4, $1, $3, 
$5, $6, $7, $8 )}' | sort
  TLSv1.3   0x13,0x01          TLS_AES_128_GCM_SHA256        Kx=any 
Au=any               Enc=AESGCM(128)  Mac=AEAD
  TLSv1.3   0x13,0x02          TLS_AES_256_GCM_SHA384        Kx=any 
Au=any               Enc=AESGCM(256)  Mac=AEAD
  TLSv1.3   0x13,0x03    TLS_CHACHA20_POLY1305_SHA256        Kx=any 
Au=any    Enc=CHACHA20/POLY1305(256)  Mac=AEAD
n0$

> Note that Apache requires a patch that was commited 4 weeks ago to
> support TLS 1.3. It just seems to make TLS 1.3 known to the ...

I'll look around for that, thank you!

Dennis




From rsalz at akamai.com  Mon Apr 30 15:52:43 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 30 Apr 2018 15:52:43 +0000
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <20180429104326.GA21314@roeckx.be>
References: <20180429104326.GA21314@roeckx.be>
Message-ID: <A60CBF9A-4C9A-4CC8-A995-1F0CCE2EA7F7@akamai.com>

Akamai has had millions of connections with megabytes of data exchanged. This is with partial deployment on our network, and requiring customers to opt in to enable beta-testing.  We have found no issues.  We don't do 0RTT. We are using our own server.

I was surprised by how many connections and how much data we are already seeing.  I think that makes a very strong argument that TLS 1.3 should be enabled by default if it all possible.


From rsalz at akamai.com  Mon Apr 30 19:01:23 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 30 Apr 2018 19:01:23 +0000
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <A60CBF9A-4C9A-4CC8-A995-1F0CCE2EA7F7@akamai.com>
References: <20180429104326.GA21314@roeckx.be>
 <A60CBF9A-4C9A-4CC8-A995-1F0CCE2EA7F7@akamai.com>
Message-ID: <8EC62B1C-7FD7-45EB-B03D-9C7B03B96F76@akamai.com>

Sorry, typo.  We've had hundreds of millions of connections, with megabytes of data exchanged."

?On 4/30/18, 11:52 AM, "Salz, Rich" <rsalz at akamai.com> wrote:

    Akamai has had millions of connections with megabytes of data exchanged. This is with partial deployment on our network, and requiring customers to opt in to enable beta-testing.  We have found no issues.  We don't do 0RTT. We are using our own server.
    
    I was surprised by how many connections and how much data we are already seeing.  I think that makes a very strong argument that TLS 1.3 should be enabled by default if it all possible.
    
    


From dclarke at blastwave.org  Mon Apr 30 19:36:15 2018
From: dclarke at blastwave.org (Dennis Clarke)
Date: Mon, 30 Apr 2018 15:36:15 -0400
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <8EC62B1C-7FD7-45EB-B03D-9C7B03B96F76@akamai.com>
References: <20180429104326.GA21314@roeckx.be>
 <A60CBF9A-4C9A-4CC8-A995-1F0CCE2EA7F7@akamai.com>
 <8EC62B1C-7FD7-45EB-B03D-9C7B03B96F76@akamai.com>
Message-ID: <0e7eb0d1-a0cf-fceb-b997-d2223b5694e7@blastwave.org>

On 30/04/18 03:01 PM, Salz, Rich via openssl-users wrote:
> Sorry, typo.  We've had hundreds of millions of connections, with megabytes of data exchanged."
> 

The issue is most likely that no one "in the wild" has done any testing 
of significance.

I can certainly see tls1.2 exchange but there is nothing for tls1.3 and
so I am working on getting a site up pronto ( in the wild ) to test.

thus :

subject=CN = www.openssl.org

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3136 bytes and written 344 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
     Protocol  : TLSv1.2
     Cipher    : ECDHE-RSA-AES256-GCM-SHA384
etc etc etc

However tls1_3 results in .. not much, yet.


Dennis

From rsalz at akamai.com  Mon Apr 30 19:48:39 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 30 Apr 2018 19:48:39 +0000
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <0e7eb0d1-a0cf-fceb-b997-d2223b5694e7@blastwave.org>
References: <20180429104326.GA21314@roeckx.be>
 <A60CBF9A-4C9A-4CC8-A995-1F0CCE2EA7F7@akamai.com>
 <8EC62B1C-7FD7-45EB-B03D-9C7B03B96F76@akamai.com>
 <0e7eb0d1-a0cf-fceb-b997-d2223b5694e7@blastwave.org>
Message-ID: <042FBF10-B77A-4441-A5E4-02218D0AA379@akamai.com>

>    The issue is most likely that no one "in the wild" has done any testing 
    of significance.

I thought the Akamai numbers were significant.
    
    I can certainly see tls1.2 exchange but there is nothing for tls1.3 and
    so I am working on getting a site up pronto ( in the wild ) to test.

I am sorry if it wasn't clear, but I was referring to *Akamai* not *OpenSSL.*  Let me repost the whole message edited a bit.

AKAMAI has partially deployed TLS 1.3 on one of its networks using its own server. Customer can opt-in to beta-test.  AKAMAI has already seen hundreds of millions of connections, with [xxx, elided] megabytes of data exchanged.   AKAMAI has found no issues.  AKAMAI does not do 0RTT. This is production traffic, not staging or test. AKAMAI has received no customer complaints.

I was surprised by how many connections and how much data AKAMAI is already seeing.  I think that makes a very strong argument that TLS 1.3 should be enabled by default if it all possible.




From dclarke at blastwave.org  Mon Apr 30 20:55:49 2018
From: dclarke at blastwave.org (Dennis Clarke)
Date: Mon, 30 Apr 2018 16:55:49 -0400
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <042FBF10-B77A-4441-A5E4-02218D0AA379@akamai.com>
References: <20180429104326.GA21314@roeckx.be>
 <A60CBF9A-4C9A-4CC8-A995-1F0CCE2EA7F7@akamai.com>
 <8EC62B1C-7FD7-45EB-B03D-9C7B03B96F76@akamai.com>
 <0e7eb0d1-a0cf-fceb-b997-d2223b5694e7@blastwave.org>
 <042FBF10-B77A-4441-A5E4-02218D0AA379@akamai.com>
Message-ID: <3b56faa2-b145-1496-001e-38ecff7729fe@blastwave.org>

On 30/04/18 03:48 PM, Salz, Rich via openssl-users wrote:
>   I think that makes a very strong argument that TLS 1.3 should be enabled by default if it all possible.


Question would be "why would it not be?"

dc

From openssl-users at dukhovni.org  Mon Apr 30 20:58:07 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 30 Apr 2018 16:58:07 -0400
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <3b56faa2-b145-1496-001e-38ecff7729fe@blastwave.org>
References: <20180429104326.GA21314@roeckx.be>
 <A60CBF9A-4C9A-4CC8-A995-1F0CCE2EA7F7@akamai.com>
 <8EC62B1C-7FD7-45EB-B03D-9C7B03B96F76@akamai.com>
 <0e7eb0d1-a0cf-fceb-b997-d2223b5694e7@blastwave.org>
 <042FBF10-B77A-4441-A5E4-02218D0AA379@akamai.com>
 <3b56faa2-b145-1496-001e-38ecff7729fe@blastwave.org>
Message-ID: <080A1B7F-D97E-4192-884D-6D20DEF283E5@dukhovni.org>



> On Apr 30, 2018, at 4:55 PM, Dennis Clarke <dclarke at blastwave.org> wrote:
> 
> Question would be "why would it not be?"

Interoperability issues with middle-boxes or existing software written for TLS 1.2.

-- 
	Viktor.


From johanna at icir.org  Mon Apr 30 20:47:37 2018
From: johanna at icir.org (Johanna Amann)
Date: Mon, 30 Apr 2018 16:47:37 -0400
Subject: [openssl-users] Extracting ResponderID from OCSP in OpenSSL 1.1
Message-ID: <20180430204731.2blfkzf3mejxdrto@Beezling.local>

Hi,

I wanted to check if it is still possible to extract the ResponderID from
a OCSP BasicResponse.

In OpenSSL 1.0 we used this code to do this:

resp_id is of type OCSP_RESPID*:

if (resp_id->type == V_OCSP_RESPID_NAME)
	X509_NAME_print_ex(bio, resp_id->value.byName, 0, XN_FLAG_ONELINE);
else if (resp_id->type == V_OCSP_RESPID_KEY)
	i2a_ASN1_STRING(bio, resp_id->value.byKey, V_ASN1_OCTET_STRING);

In OpenSSL 1.1, OCSP_RESPID seems to be a private type and there do not
seem to be any functions to access the byName/byKey fields.

Is it still possible to get to these values? If yes could someone please
point me to where to look?

Thank you very much,
 Johanna

From matt at openssl.org  Mon Apr 30 21:41:25 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 30 Apr 2018 22:41:25 +0100
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <3b56faa2-b145-1496-001e-38ecff7729fe@blastwave.org>
References: <20180429104326.GA21314@roeckx.be>
 <A60CBF9A-4C9A-4CC8-A995-1F0CCE2EA7F7@akamai.com>
 <8EC62B1C-7FD7-45EB-B03D-9C7B03B96F76@akamai.com>
 <0e7eb0d1-a0cf-fceb-b997-d2223b5694e7@blastwave.org>
 <042FBF10-B77A-4441-A5E4-02218D0AA379@akamai.com>
 <3b56faa2-b145-1496-001e-38ecff7729fe@blastwave.org>
Message-ID: <c2d706c4-17c6-2177-21ce-3ae470547f0e@openssl.org>



On 30/04/18 21:55, Dennis Clarke wrote:
> On 30/04/18 03:48 PM, Salz, Rich via openssl-users wrote:
>> ? I think that makes a very strong argument that TLS 1.3 should be
>> enabled by default if it all possible.
> 
> 
> Question would be "why would it not be?"

TLSv1.3 behaves differently to TLSv1.2. Applications written with
TLSv1.2 in mind might not work as expected when TLSv1.3 is negotiated.

Some of the issues that might be encountered are here:

https://wiki.openssl.org/index.php/TLS1.3

We have already seen a handful of issues. For example in this one an
application has implemented a PSK callback. Due to the way PSK works in
TLSv1.3 the callback can get called earlier in the process than in
TLSv1.2. Suddenly in the presence of TLSv1.3 this particular application
callback has started to crash (we don't know why yet):

https://github.com/openssl/openssl/issues/6110


Matt

From matt at openssl.org  Mon Apr 30 21:47:20 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 30 Apr 2018 22:47:20 +0100
Subject: [openssl-users] Extracting ResponderID from OCSP in OpenSSL 1.1
In-Reply-To: <20180430204731.2blfkzf3mejxdrto@Beezling.local>
References: <20180430204731.2blfkzf3mejxdrto@Beezling.local>
Message-ID: <4791b5a5-62d4-5aea-859a-2d5dbf770ec9@openssl.org>



On 30/04/18 21:47, Johanna Amann wrote:
> Hi,
> 
> I wanted to check if it is still possible to extract the ResponderID from
> a OCSP BasicResponse.
> 
> In OpenSSL 1.0 we used this code to do this:
> 
> resp_id is of type OCSP_RESPID*:
> 
> if (resp_id->type == V_OCSP_RESPID_NAME)
> 	X509_NAME_print_ex(bio, resp_id->value.byName, 0, XN_FLAG_ONELINE);
> else if (resp_id->type == V_OCSP_RESPID_KEY)
> 	i2a_ASN1_STRING(bio, resp_id->value.byKey, V_ASN1_OCTET_STRING);
> 
> In OpenSSL 1.1, OCSP_RESPID seems to be a private type and there do not
> seem to be any functions to access the byName/byKey fields.

The functions OCSP_resp_get0_id() and OCSP_resp_get1_id() give you
access to these fields. See:

https://www.openssl.org/docs/man1.1.0/crypto/OCSP_resp_get0_id.html

Matt


> 
> Is it still possible to get to these values? If yes could someone please
> point me to where to look?
> 
> Thank you very much,
>  Johanna
> 

From dclarke at blastwave.org  Mon Apr 30 22:16:36 2018
From: dclarke at blastwave.org (Dennis Clarke)
Date: Mon, 30 Apr 2018 18:16:36 -0400
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <c2d706c4-17c6-2177-21ce-3ae470547f0e@openssl.org>
References: <20180429104326.GA21314@roeckx.be>
 <A60CBF9A-4C9A-4CC8-A995-1F0CCE2EA7F7@akamai.com>
 <8EC62B1C-7FD7-45EB-B03D-9C7B03B96F76@akamai.com>
 <0e7eb0d1-a0cf-fceb-b997-d2223b5694e7@blastwave.org>
 <042FBF10-B77A-4441-A5E4-02218D0AA379@akamai.com>
 <3b56faa2-b145-1496-001e-38ecff7729fe@blastwave.org>
 <c2d706c4-17c6-2177-21ce-3ae470547f0e@openssl.org>
Message-ID: <ea56e345-7370-9b12-7560-cf4c2ef8a510@blastwave.org>

On 30/04/18 05:41 PM, Matt Caswell wrote:
> 
> 
> On 30/04/18 21:55, Dennis Clarke wrote:
>> On 30/04/18 03:48 PM, Salz, Rich via openssl-users wrote:
>>>  ? I think that makes a very strong argument that TLS 1.3 should be
>>> enabled by default if it all possible.
>>
>>
>> Question would be "why would it not be?"
> 
> TLSv1.3 behaves differently to TLSv1.2. Applications written with
> TLSv1.2 in mind might not work as expected when TLSv1.3 is negotiated.
> 
> Some of the issues that might be encountered are here:
> 
> https://wiki.openssl.org/index.php/TLS1.3
> 
> We have already seen a handful of issues. For example in this one an
> application has implemented a PSK callback. Due to the way PSK works in
> TLSv1.3 the callback can get called earlier in the process than in
> TLSv1.2. Suddenly in the presence of TLSv1.3 this particular application
> callback has started to crash (we don't know why yet):
> 
> https://github.com/openssl/openssl/issues/6110
> 

I'm having no joy with apache 2.4.33 which just tossed a sigILL :

Reading mod_ssl.so
t at 1 (l at 1) program terminated by signal ILL (illegal opcode)
0xffffffff70d97320: TLSv1_2_enc_data       :    .word            0xffffffff
Current function is ssl_init_ctx_protocol
   613       ctx = SSL_CTX_new(method);
(dbx) where 

current thread: t at 1
   [1] 0xffffffff70d97320(0x1002dc9d0, 0x0, 0x0, 0xfffffffffffffff8, 
0x0, 0x1002dccf8), at 0xffffffff70d97320
   [2] SSL_CTX_new(0xffffffff70d942b8, 0x1002dc9d0, 0x3b40, 0x2, 
0xffffffff742619fc, 0xffffffff74367460), at 0xffffffff7424bc00
=>[3] ssl_init_ctx_protocol(s = 0x10026ddc0, p = 0x1001f8a68, ptemp = 
0x100228c68, mctx = 0x1002be698), line 613 in "ssl_engine_init.c"
   [4] ssl_init_ctx(s = 0x10026ddc0, p = 0x1001f8a68, ptemp = 
0x100228c68, mctx = 0x1002be698), line 1076 in "ssl_engine_init.c"
   [5] ssl_init_server_ctx(s = 0x10026ddc0, p = 0x1001f8a68, ptemp = 
0x100228c68, sc = 0x1002be658, pphrases = 0x1002b51a0), line 1740 in 
"ssl_engine_init.c"
   [6] ssl_init_ConfigureServer(s = 0x10026ddc0, p = 0x1001f8a68, ptemp 
= 0x100228c68, sc = 0x1002be658, pphrases = 0x1002b51a0), line 1842 in 
"ssl_engine_init.c"
   [7] ssl_init_Module(p = 0x1001f8a68, plog = 0x100226c58, ptemp = 
0x100228c68, base_server = 0x10022ac78), line 369 in "ssl_engine_init.c"
   [8] ap_run_post_config(pconf = 0x1001f8a68, plog = 0x100226c58, ptemp 
= 0x100228c68, s = 0x10022ac78), at 0x10007d094
   [9] main(argc = 3, argv = 0xffffffff7ffff6d8), line 739 in "main.c"
(dbx) list
   613       ctx = SSL_CTX_new(method);
   614
   615       mctx->ssl_ctx = ctx;
   616
   617       SSL_CTX_set_options(ctx, SSL_OP_ALL);
   618
   619   #if OPENSSL_VERSION_NUMBER < 0x10100000L
   620       /* always disable SSLv2, as per RFC 6176 */
   621       SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
   622
(dbx)

I'm digging around in there now ...

(dbx) listi 612, 613
   612   #endif
   613       ctx = SSL_CTX_new(method);
0xffffffff6e689b60: ssl_init_ctx_protocol+0x0330:       ldx      [%fp + 
1991], %o0
0xffffffff6e689b64: ssl_init_ctx_protocol+0x0334:       call 
_PROCEDURE_LINKAGE_TABLE_+0x1160 [PLT] ! 0xffffffff6e9afa60
0xffffffff6e689b68: ssl_init_ctx_protocol+0x0338:       nop
0xffffffff6e689b6c: ssl_init_ctx_protocol+0x033c:       mov      %o0, %o1
0xffffffff6e689b70: ssl_init_ctx_protocol+0x0340:       stx      %o1, 
[%fp + 1999]

(dbx) print method
method = 0xffffffff70d942b8
(dbx) x 0xffffffff70d942b8/8x
0xffffffff70d942b8: DTLSv1_2_enc_data+0x0400:    0x0001 0x0000 0x0000 
0x0000 0x0000 0x0000 0x0000 0x0000
(dbx)
(dbx) x 0xffffffff6e9afa60/16x
0xffffffff6e9afa60: _PROCEDURE_LINKAGE_TABLE_+0x1160 [PLT]:      0x0100 
0x0000 0x0b22 0xf6d1 0x8239 0x60bf 0x81c0 0x6000
0xffffffff6e9afa70: _PROCEDURE_LINKAGE_TABLE_+0x1170 [PLT]:      0x0100 
0x0000 0x0100 0x0000 0x0100 0x0000 0x0100 0x0000
(dbx)

no idea why an illegal opcode slipped into the mix here but I may revert
back to 1.1.0h and do a sanity check, run httpd inside the debugger or
at least the foregorund and then try 1.1.1-pre5 again. I don't want to
have to unwind frames here and try to figure out why that call was sick.

oodles of fun.

dc