OpenSSL version 1.1.0l published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


   OpenSSL version 1.1.0l released
   ===

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

   The OpenSSL project team is pleased to announce the release of
   version 1.1.0l of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

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

   OpenSSL 1.1.0l 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.0l.tar.gz
  Size: 5294857
  SHA1 checksum: 6e3507b29e2630f56023887d1f7d7ba1f584819b
  SHA256 checksum: 
74a2f756c64fd7386a29184dc0344f4831192d61dc2481a93a4c5dd727f41148

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.0l.tar.gz
openssl sha256 openssl-1.1.0l.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13okkACgkQ2cTSbQ5g
RJFu5wf9HCvluEc1W1UwNqaw48n3g1ZclRdexYFO12HtUTTtriUwu0BPorvzHVmo
x4I0JzUxLeRXyS2kdBBPJC0OlPlrZMkWfwNy9IF2BRFGcMuGhjIOu60FfRNkGOM8
63RdIuSy1oPnwL4kUOdQi4pru1UcQVx25l4tpB6pLMKKgioGc1x75mP+C/lxhM16
PvPSo8pETU60V2QFaxzbfOqbS8LJhbO2m+dYCzgGy6Rjrd2CyzyZbtKC/bWoyMhW
s3jQ4oBjGh28y/mrzLup9oXP4f4/GlWajxd+pFXsj8xRfwEN7Zwg7eLlg6uZh6Cq
4KhsFKHIKgvba/lekhASdh71BdVVSA==
=na1Q
-END PGP SIGNATURE-

OpenSSL version 1.0.2t published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


   OpenSSL version 1.0.2t released
   ===

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

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2t of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

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

   OpenSSL 1.0.2t 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.0.2t.tar.gz
  Size: 5355422
  SHA1 checksum: 8ac3fd379cf8c8ef570abb51ec52a88fd526f88a
  SHA256 checksum: 
14cb464efe7ac6b54799b34456bd69558a749a4931ecfd9cf9f71d7881cac7bc

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.0.2t.tar.gz
openssl sha256 openssl-1.0.2t.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13pssACgkQ2cTSbQ5g
RJFr9wf/X0fke/exS13hQb4h9RqE9fYouVbSNKTKhLp9X8BtYUOtUTjO5ispKt+1
BGWBotApoXBTopOsdJVXhzLtYst2YdKEtvyJAEFyxfpJa2PL4jmo5zxk93qWjDjA
u0HXR1Tu4XTLlE3EfqbfV/8bVO4kntTCk/xvg0gql1LUCVIRtjmqmsKOe7MJAHkH
94yb3kRFMpXb2YB6/zrK+ZuruL5ejTZCcXG7Dx9+LH5X7E/8KFDknk0Zo6w6970I
LbrXjtAOfHtVEK5XAFESCkMkjNqahopOs90AtemiOt1oOsNztjr7bVFHqJ3/oBMf
OYamiO1W2IhyxnPbet6zUDYG0FtYpw==
=sBvh
-END PGP SIGNATURE-

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

OpenSSL Security Advisory [10 September 2019]
=

ECDSA remote timing attack (CVE-2019-1547)
==

Severity: Low

Normally in OpenSSL EC groups always have a co-factor present and this is used
in side channel resistant code paths. However, in some cases, it is possible to
construct a group using explicit parameters (instead of using a named curve). In
those cases it is possible that such a group does not have the cofactor present.
This can occur even where all the parameters match a known named curve.

If such a curve is used then OpenSSL falls back to non-side channel resistant
code paths which may result in full key recovery during an ECDSA signature
operation.

In order to be vulnerable an attacker would have to have the ability to time
the creation of a large number of signatures where explicit parameters with no
co-factor present are in use by an application using libcrypto.

For the avoidance of doubt libssl is not vulnerable because explicit parameters
are never used.

OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue.

OpenSSL 1.1.1 users should upgrade to 1.1.1d
OpenSSL 1.1.0 users should upgrade to 1.1.0l
OpenSSL 1.0.2 users should upgrade to 1.0.2t

This issue was reported by Cesar Pereida García, Sohaib ul Hassan,
Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya, and Billy Brumley. The
fix was developed by Billy Brumley. It was reported to OpenSSL on 5th August
2019.


Fork Protection (CVE-2019-1549)
===

Severity: Low

OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was
intended to include protection in the event of a fork() system call in order to
ensure that the parent and child processes did not share the same RNG state.
However this protection was not being used in the default case.

A partial mitigation for this issue is that the output from a high precision
timer is mixed into the RNG state so the likelihood of a parent and child
process sharing state is significantly reduced.

If an application already calls OPENSSL_init_crypto() explicitly using
OPENSSL_INIT_ATFORK then this problem does not occur at all.

OpenSSL version 1.1.1 is affected by this issue.

OpenSSL 1.1.1 users should upgrade to 1.1.1d

This issue was reported by Matt Caswell. The fix was developed by Matthias
St. Pierre. It was reported to OpenSSL on 27th May 2019.


Padding Oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey (CVE-2019-1563)


Severity: Low

In situations where an attacker receives automated notification of the success
or failure of a decryption attempt an attacker, after sending a very large
number of messages to be decrypted, can recover a CMS/PKCS7 transported
encryption key or decrypt any RSA encrypted message that was encrypted with the
public RSA key, using a Bleichenbacher padding oracle attack. Applications are
not affected if they use a certificate together with the private RSA key to the
CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to
decrypt.

OpenSSL 1.1.1 users should upgrade to 1.1.1d
OpenSSL 1.1.0 users should upgrade to 1.1.0l
OpenSSL 1.0.2 users should upgrade to 1.0.2t

This issue was reported by and the fix developed by Bernd Edlinger. It was
reported to OpenSSL on 21st August 2019.


Note
=

OpenSSL 1.0.2 is currently only receiving security updates. Support for 1.0.2
will end on 31st December 2019.

Support for 1.1.0 ends on 11th September 2019 so 1.1.0l is expected to be the
last 1.1.0 release.

Users of these versions should upgrade to OpenSSL 1.1.1.


References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20190910.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-

iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13vK0ACgkQ2cTSbQ5g
RJGJIgf+Me900bLV9TrVDWvNRQbuRe0tOPPhP59J4tJAJiRZ1GG0JV2YITQynjTP
hrz9mvajgWbkGYlTZmPVFOdJr7LKbrUrxk7shEfXqmiiCLG8tHYiCe3PF+/Cy7gA
X1vY9CDfv//3VSqOLM9RM3CCcWAAv3KeP851X0PgCiMVvGAJbYOu3bmB+KsEKFzm
fWRDabUMbl1KCSgCIvvlNv0bKR/GfpW3cWruUvG0sfjyPWwS+yn8z0T3/ibFJqkb
Cmuqa3/kC9uZg8AhiODR+nz6D1mC2UiNZ2Wa/XO6O68rO/y3ZKbaiMGLze1qJep5
3PnybOw8b3JvpVRFYw09YwgLObBX8w==
=8bP1
-END PGP SIGNATURE-

Re: Openssl-1.0.2t availability

[Jakob Bohm via openssl-users]

On 09/09/2019 20:56, Nikki D'Ambra wrote:

Hello,

I was wondering when the latest version openssl, version 1.0.2t will 
be available for public download?


Announcement is 2019-09-10 between 12:00 and 16:00 UTC approximately.  
That's about 17 to 21 hours after your question.



Enjoy

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

Re: Compiling OpenSSL 1.1 - certs directory is empty, how to obtain?

[Salz, Rich via openssl-users]

Another great source is https://github.com/nabla-c0d3/trust_stores_observatory

One-stop shopping for all of apple, Android, Windows, NSS, OpenJDK, Oracle Java.

Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

[Jakob Bohm via openssl-users]

On 29/08/2019 17:05, Hubert Kario wrote:

On Wednesday, 28 August 2019 23:20:49 CEST Marcelo Lauxen wrote:

...

that server is willing to negotiate ECDHE_RSA ciphers, you'd be better off
disabling ciphers that use DHE and RSA key exchange and using ECDHE_RSA
instead of trying to make 1024 bit work – it really is weak and should not be
used (see also: LOGJAM)



Where in the LOGJAM papers does it say that 1024 bit DH is too little,
provided the group is not shared among millions of servers?

Where, does it reliably say that ECDH with a choice of very few published
groups is more secure than DH with random group parameters shared among
a much smaller number of connections and servers?

Also note that the following factors make it necessary to support
traditional DHE for compatibility:

1. Red Hat OpenSSL builds until a few years ago disabled EC support.

2. Microsoft (and the TLS protocol specs themselves) until fairly
  recently allowed ECDHE only with (EC)DSA server certificates, which
  are not as easily available as RSA certs.

3. The "supported groups" TLS extension cannot be used without jamming
  the TLS clients into a short list of fixed DH groups.  Thus servers
  have to ignore that extension and use heuristic guesses to choose the
  DH strength.


Enjoy

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

Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

[Salz, Rich via openssl-users]

  *   I've another question, based on your suggestion Salz Rich, this config 
@SECLEVEL can be set per host/domain, or is it impossible?

It totally depends on which webserver you are running and what it’s 
configuration allows. I’m not able to answer webserver config questions BTW.

Re: client certs with no subjectName only SAN

[Erwann Abalea via openssl-users]

Bonjour,

Having a critical extension adds 3 octets (the BOOLEAN tag, length=1, 
value=0xff). It may, as a side effect, enlarge the number of octets necessary 
to encode some structure size.

Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL 
keeps them by default).

If size is a hard constraint:
 - you can probably remove the emailProtection EKU (it's an OID, you'll gain 10 
octets). Depending on your use-case, you may need to tweak the EKU (or remove 
it completely).
 - SKI and AKI extensions may not be necessary
 - Key Usage may be marked as non critical (it's a SHOULD in PKIX)

A quick reading of RFC8002 tells me that you may need to include the 
IssuerAltName extension as well?

Cordialement,
Erwann Abalea

Le 16/08/2019 17:11, « openssl-users au nom de Robert Moskowitz » 
 a écrit :

Viktor,


On 8/16/19 8:41 AM, Viktor Dukhovni wrote:
>> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users 
 wrote:
>>
>> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says 
"SHOULD mark subjectAltName as non-critical"
> This is wrong.  When the subject DN is empty, the subjectAltName should be
> marked as critical.  IIRC some Java implementations reject the certificate
> otherwise.

I have just created a client cert with empty subjectName and critical 
subjectAltName.  Interestingly, it is 4 bytes larger than the earlier 
non-critical SAN cert.  See below for the output of the cert.
    
>> I can believe that OpenSSL doesn't support empty subjectName's.  An 
empty one, with no relative disintuished name components, is not the same as 
not present.
> OpenSSL supports empty (empty RDN sequence) subject DNs.
> The "-subj /" option is one way to make that happen.
>
> Empty is of course different from "absent", which is not
> possible, since the subject DN is a required component of
> an X.509 certificate.

I now have it clear that Empty SN is NOT a cert with NO SN.  It is there 
with null content.

Thank you all.

$ openssl x509 -noout -text -in $dir/certs/device2.cert.pem
Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number:
 c9:8f:b2:7b:e1:95:74:d0
 Signature Algorithm: ED25519
 Issuer: CN = 2001:24:28:14::/64
 Validity
 Not Before: Aug 16 14:54:58 2019 GMT
 Not After : Aug 25 14:54:58 2020 GMT
 Subject:
 Subject Public Key Info:
 Public Key Algorithm: ED25519
 ED25519 Public-Key:
 pub:
 69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50:
 c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8:
 4c:a5
 X509v3 extensions:
 X509v3 Basic Constraints:
 CA:FALSE
 Netscape Cert Type:
     SSL Client, S/MIME
 Netscape Comment:
 OpenSSL Generated Client Certificate
 X509v3 Subject Key Identifier:
8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD
 X509v3 Authority Key Identifier:
keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA

 X509v3 Key Usage: critical
 Digital Signature, Non Repudiation, Key Encipherment
 X509v3 Extended Key Usage:
 TLS Web Client Authentication, E-mail Protection
 X509v3 Subject Alternative Name: critical
 IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C
 Signature Algorithm: ED25519
  01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1:
  4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46:
  dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a:
  ba:1a:b4:17:c0:bb:0f:da:be:02

Re: client certs with no subjectName only SAN

[Salz, Rich via openssl-users]

>In the same paragraph, the sentence before the one you're quoting says "If 
> the subject field contains an empty sequence, then the issuing CA MUST 
> include a subjectAltName extension that is marked as critical."

>It's not possible to have a missing subject name in a certificate, the 
> field is not OPTIONAL.
  
You are of course correct.  Thanks Erwann.  (He has forgotten more about ASN1 
than I ever knew :)

Re: Acquire Entropy for embedded platform

[Salz, Rich via openssl-users]

  *   Honestly, I’d like to add CPU Jitter to OpenSSL as one of its default 
entropy sources.
  *   I dread the effort that this would entail.

Open an issue and maybe someone with an older platform will work on doing it.

I don’t think the project has any need to support such things.  (Members of the 
project working for companies, perhaps)

Re: Acquire Entropy for embedded platform

[Jakob Bohm via openssl-users]

Not just dedicated black box rngs in verious chips (such as
multifunction I/O chips or the old Intel BIOS chip), but also
general hardware that happens to have plenty of inherent
randomness due to its design or implementation.

The simple easy to add RNG circuits include some completely
open discrete designs if that's desired.

On 16/08/2019 12:53, Dr Paul Dale wrote:
I agree.  Using internal hardware in the processor for entropy depends 
on everything.  Each processor needs to be independently quantified 
and not doing so becomes a risk assessment.


As for hardware sources, they are essentially black boxes and could 
contain anything.  It is extremely difficult, if not impossible, to 
tell if the hardware RNG is good or not.  This doesn’t mean that they 
should not be used, it just means that using them involves another 
risk assessment.




On 16 Aug 2019, at 8:42 pm, Jakob Bohm via openssl-users 
mailto:openssl-users@openssl.org>> wrote:


[Top posting for consistency]

More than OS dependency, this depends on the exact hardware on the 
platform:

CPU, support chips, peripheral chips.   Usually some of these can provide
much more randomness than the highly predictable time of day/year RTC 
clock.
 And if none do, there are simple RNG hardware designs that could be 
added
in a corner of the circuit, either on a plugin board or as part of a 
board

already customized to the application.


On 16/08/2019 11:33, Dr Paul Dale wrote:
Two bits of RTC is nowhere near enough entropy.  I could break two 
bits by hand in a few seconds — there are only four possibilities.


The best outcome is an hardware random number generator.  These are 
often not readily available.


Next would be waiting for enough entropy from interrupts, timers and 
the like.


You didn’t specify what operating system/kernel you are using so 
further advise is less than useful.



On 16 Aug 2019, at 7:26 pm, Chitrang Srivastava 
<mailto:chitrang.srivast...@gmail.com> 
<mailto:chitrang.srivast...@gmail.com>> wrote:


Hi,

I am working on an embedded platform and now ported openssl 1.1.1b
TLS 1.2/1.3 is working fine.
While analysing random number , Rand pool initialization calls 
where I am returning like this ,

size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
{
        return rand_pool_entropy_available(pool);
}
As noticed that *rand_unix.c* has an implementation wcih samples 2 
bits of RTC, would that give enough entropy or any other 
recommendation to have enough entropy for embedded platforms?





Enjoy

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

Re: client certs with no subjectName only SAN

[Erwann Abalea via openssl-users]

Bonjour,

In the same paragraph, the sentence before the one you're quoting says "If the 
subject field contains an empty sequence, then the issuing CA MUST include a 
subjectAltName extension that is marked as critical."

It's not possible to have a missing subject name in a certificate, the field is 
not OPTIONAL.

Cordialement,
Erwann Abalea

Le 15/08/2019 22:13, « openssl-users au nom de Salz, Rich via openssl-users » 
 a écrit 
:

subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says 
"SHOULD mark subjectAltName as non-critical"

    I can believe that OpenSSL doesn't support empty subjectName's.  An empty 
one, with no relative disintuished name components, is not the same as not 
present.

Re: Acquire Entropy for embedded platform

[Jakob Bohm via openssl-users]

[Top posting for consistency]

More than OS dependency, this depends on the exact hardware on the platform:
CPU, support chips, peripheral chips.   Usually some of these can provide
much more randomness than the highly predictable time of day/year RTC clock.
 And if none do, there are simple RNG hardware designs that could be added
in a corner of the circuit, either on a plugin board or as part of a board
already customized to the application.


On 16/08/2019 11:33, Dr Paul Dale wrote:
Two bits of RTC is nowhere near enough entropy.  I could break two 
bits by hand in a few seconds — there are only four possibilities.


The best outcome is an hardware random number generator.  These are 
often not readily available.


Next would be waiting for enough entropy from interrupts, timers and 
the like.


You didn’t specify what operating system/kernel you are using so 
further advise is less than useful.



On 16 Aug 2019, at 7:26 pm, Chitrang Srivastava 
<mailto:chitrang.srivast...@gmail.com>> wrote:


Hi,

I am working on an embedded platform and now ported openssl 1.1.1b
TLS 1.2/1.3 is working fine.
While analysing random number , Rand pool initialization calls where 
I am returning like this ,

size_t *rand_pool_acquire_entropy*(RAND_POOL *pool)
{
        return rand_pool_entropy_available(pool);
}
As noticed that *rand_unix.c* has an implementation wcih samples 2 
bits of RTC, would that give enough entropy or any other 
recommendation to have enough entropy for embedded platforms?


Thanks,










Enjoy

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

Re: IPv6 address encoding in commonName

[Jakob Bohm via openssl-users]

[Top posting to match]

Note that the actual DC name element is still used for actual domains 
when interacting with Microsoft Active Directory authentication, 
including associated X.509 certificates.  So it shouldn't be used for 
something contrary.


The shortest useful form in terms of certificate size would probably be:

Put an informal (but fixed format) description of the address scope in 
the user readable CN in certificates at all levels (rootCA, itemCA and 
end cert).  Put appropriate human readable organization name or 
equivalent in the O name element in rootCA and itemCA.  Make the end 
cert DN as short as possible.


For example "CN=HIT CA 2 example corp,O=example corp,C=TH" -> "CN=HIT 
factory CA xy,O=Example Chon Buri plant,C=TH" -> "CN=HIT CA for 
[...],O=In your device,C=XX" -> "CN=[2001:db8:a:b::],C=XX" (Using "XX" 
to represent the device might be in any country).


Put the actual address in the appropriate SAN in the end cert (this will 
be a binary address).


Put name restrictions in the all the CAs (intermediary and special 
purpose root), these will be a binary address and length for the allowed 
type and the appropriate "nothing" notation for all the other defined 
name restriction types except the distinguished name type.


Do not include ID number fields except the certificate serial number, 
which also protects the signature hash algorithm via randomization 
(since SHA-1 phase out began, but potentially useful for modern algorithms).


Use a short offline-compatible revocation URL such as "ex.th/xy.crl" for 
hierarchies run by the hypothetical EXample conglomerate in THailand, 
where the xy part is a very short name assigned by that conglomerate to 
the issuing central CA or factory intermCA.


On 15/08/2019 18:49, Robert Moskowitz wrote:



On 8/14/19 6:47 PM, Michael Richardson wrote:

Robert Moskowitz  wrote:
 > I am fiddling around with an intermediate CA signing cert that 
the CA's
 > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. 
Actually a
 > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be 
revised soon).


 > For a client cert, it would be easy to put the HIT in 
subjectAltName per RFC
 > 8002 (with a null subjectName), but a CA cert MUST have a 
non-empty

 > subjectName.

 > Thus all I want in this subjectName is commonName with the HIT.
 > I am looking for examples of IPv6 addresses in commonName.

I thought that RFC3779 did exactly what you want, but it does not 
define new

Subject DN, but rather a new extension that will be bound to the Subject.
(I was surprised that RFC3779 was not in the SIDR WG's list of 
documents,but

I guess it preceeded the SIDR working group, and occured in PKIX)

In ANIMA's ACP document, we have an abomination that leverages 
rfc822Name,

mostly because we figure the odds of getting anything else through
off-the-shelf CAs is nil.
Note to consumed with things in your stomach:
https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20#section-6.1.2

Jakob Bohm via openssl-users  wrote:
 > As the author of a proposal in this area, could you define a 
notation
 > for IPv6 DNs, perhaps one that actually reflects the 
hierarchical nature

 > of IPv6 addresses?

RFC3779 does some of that, but not in the DN itself.

 > You could take inspiration from the (unfortunately rarely used)
 > hierarchical DN representation of DNS names (this used the DNS
 > specific DC name components).  Overall the goal is to allow X.500
 > distinguished name restrictions to work correctly.

Yes, we could abuse the DC component.
Were you thinking about:
  DC=2001/DC=0db8


This looks closest to what is needed here, as the prefix for HHITs is 
currently proposed at /64.


So it would be DC=2001/DC=0024/DC=0028/DC=0014

But the OID for DC is bi: 0.9.2342.19200300.100.1.25

Ouch.

So I will research this more, but for this early stage in the 
development I will use:


CN=2001:24:28:14::/64

Thanks for all the comments here.



 > In practice you could follow the nibble notation as already used
 > for delegation of IPv6 reverse lookups in DNS.

so more correctly:
  DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8

 > However for the CN in the end cert you could perhaps use the full
 > DNS reverse IPv6 name
 > 
"x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa"
 > or the URL/Mail notation 
"[:::::::]"

 > where the hex notation shall be the shortest form permitted by the
 > IPv6 notation spec.

Bob, this seems like the best immediate hack to me.



Enjoy

Jakob

Enjoy

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

Re: client certs with no subjectName only SAN

[Salz, Rich via openssl-users]

subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD 
mark subjectAltName as non-critical"

I can believe that OpenSSL doesn't support empty subjectName's.  An empty one, 
with no relative disintuished name components, is not the same as not present.

Re: openssl req error with DN having a / in it

[Jakob Bohm via openssl-users]

On 15/08/2019 00:33, Jordan Brown wrote:

On 8/14/2019 2:11 PM, Robert Moskowitz wrote:

[...]
   commonName="/CN=IPv6::2001:24:28:24/64"
[...]
req: Hit end of string before finding the equals.
problems making Certificate Request 


Some systems present distinguished names using slashes as separators.  
I assume that that's what you're running into here, that your string 
is being processed as a valid RDN "CN=IPv6::2001:db8:28:24" and an 
invalid RDN "64".


You'll need to quote the slash.  I don't happen to know how, but my 
bet would be either \/ or %2F.



This is why my mail proposed CN=[2001:24:28:24::9] with no
slashes for an end cert with a specific IP and a human readable
name that would sort with related names in the CA's CN element.
Also note that the "IPv6:" notation might confuse OpenSSL or
OpenSSL derived string parsing code.

Certificates for Bluetooth MAC addresses would be a different
notation such as CN=DC-BA-98-76-54-32 for a 48-bit MAC address,
or (to reuse name restrictions on via IPv6 SANs), the equivalent
[fe80::dcba:98ff:fe76:5432].

I don't understand what use case Moskowitz wants for a subnet
mask length such as /64 in an end cert.

P.S. 2001:db8::/32 is the official prefix for use in examples.

Enjoy

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

Re: IPv6 address encoding in commonName

[Salz, Rich via openssl-users]

RFC 8002 (with a null subjectName), but a CA cert MUST have a non-empty 
subjectName.

Non-empty subjectName or non-empty commonName within the subject name?

Shrug.  Doesn't matter, I guess.  Just populate it with the string version of 
the HIT name, something like
CN=IP Address 2001:27:dcfc:cb8:d53g:5364:48bj
?

>My searches today have come up empty.
  
I tried crt.sh and also came up empty; https://crt.sh/?CAName=%25%3A%25  This 
is not surprising since I would not expect any public CA's to have this kind of 
thing.

  

Re: IPv6 address encoding in commonName

[Jakob Bohm via openssl-users]

On 14/08/2019 04:55, Robert Moskowitz wrote:
I am fiddling around with an intermediate CA signing cert that the 
CA's 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. 
Actually a Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to 
be revised soon).


For a client cert, it would be easy to put the HIT in subjectAltName 
per RFC 8002 (with a null subjectName), but a CA cert MUST have a 
non-empty subjectName.


Thus all I want in this subjectName is commonName with the HIT.

I am looking for examples of IPv6 addresses in commonName.

My searches today have come up empty.


If no one comes up with good established practice examples, here are
some ideas you may work on.

For CA certificates that are not self-signed end certs, it would be
practical to use a CN that is intentionally different from the end
certs, such as "Example corp HIP CA for 2001:db8::/48" .

As the author of a proposal in this area, could you define a notation
for IPv6 DNs, perhaps one that actually reflects the hierarchical nature
of IPv6 addresses?

You could take inspiration from the (unfortunately rarely used)
hierarchical DN representation of DNS names (this used the DNS
specific DC name components).  Overall the goal is to allow X.500
distinguished name restrictions to work correctly.

In practice you could follow the nibble notation as already used
for delegation of IPv6 reverse lookups in DNS.

However for the CN in the end cert you could perhaps use the full
DNS reverse IPv6 name
"x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa"
or the URL/Mail notation "[:::::::]"
where the hex notation shall be the shortest form permitted by the
IPv6 notation spec.

Examples of boundaries where hierarchical divisions would be practical
(if making a new design, it should be useful outside the HIT/HIP
standards):

1. After the 1st nibble to cater for IANA design assignments (0 is
  special, 2 and 3 used for current live assignments, f used for
  special transmission modes such as multicast and local segment).

2. After the 2nd to 4th nibble to reflect assignments to continents
  (RIRs).  Different continents may operate under conflicting legal
  regimes for internal purposes, such as certificate privacy.

3. After the 4th to 6th nibble to reflect typical operator (LIR)
  assignments.

4. After the 6th to 8th nibble to reflect customer or other specific
  net assignments.

5. After the 14th nibble to reflect a single IEEE assigned MAC prefix
  (For example fe80:0:0:0:3a94:ed00::/88 would match the net local
  addresses of NETGEAR hardware using the 38-94-ED OUI block).

6. After the 18th nibble to reflect a single IEEE assigned MAC
  prefix excluding similar-looking non-MAC addresses (For example
  fe80:0:0:0:3a94:edff:fe00:/104 for that same block).

7. Even later nibbles to reflect assignment of part of an OUI block
  to a factory or production line that generates certificates for
  devices as they are manufactured.





Enjoy

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

Re: Does BIO_read() behave differently on diff architectures?

[Venkata Veldanda via openssl-users]

@Andrew - Thanks for pointing that out. Indeed, that was the issue.




Get Outlook for Android







On Fri, Aug 9, 2019 at 6:18 PM +0530, "Lynch, Andrew"  
wrote:




















Hi,


 


Your issue is not with BIO_read(), but with the differing signedness of the 
char type on your two platforms.


 


On your PPC platform the char type defaults to unsigned, on your x86 platform 
it is signed.  The %x format expects an unsigned int, so on x86 the
 signed char values are being sign-extended to int which adds the ff to any 
values where the high bit is set (i.e. seen as negative).


 


One possible fix:  Change "char *ptr = buf;" to "unsigned char *ptr = buf;", 
then you should get the expected output.





Regards,


Andrew.


 




From: openssl-users [mailto:openssl-users-boun...@openssl.org]
On Behalf Of Venkata Veldanda via openssl-users

Sent: Friday, August 09, 2019 11:20 AM

To: openssl-users@openssl.org

Subject: Does BIO_read() behave differently on diff architectures?




 






Hi Experts,




 




I am using openssl 1.0.2 




 




I recently moved my app from a PPC to x86 platform (application is compiled on 
the respective platform) where I met an issue with BIO_read(). 




 




I read a 20bytes of data using BIO_read like following..




 




int    res = BIO_read(bio, buf, 20);




char *ptr = buf;




 




The content that I send as input is a signed file content that I get from a 
different source. The issue is that the output 'buf' is not as expected on my 
x86. The behavior is different
 on different architectures. 




 




For e.g. on intel x86 platform I get the following output with additional 
0xff padded.>> For me this is not the expected result. 




22,ff82,2b,28,06,09,2a,ff86,48,ff86,fff7,0d,02,09,02,ffa0,ff82,3b,12,30




 




This is what I was getting on my PPC platform which is as expected with the 
same app code.




22,82,2b,28,06,09,2a,86,48,86,f7,0d,02,09,02,a0,82,3b,12,30




 




Ofcourse, I need to further check on the source where/how the signed file was 
generated, but does anyone have any idea if BIO_read() has any specific 
handling with repsect to architectures?.
 I'd rule out the endianess factor as I would expect the entire byte order to 
be reversed if so. 




 




I print the above output using the following code. 







INFO( STR(" ..> Header@%02d: %02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,"




                                    
"%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x",




                     ptr-buf, *(ptr+0),*(ptr+1),*(ptr+2),*(ptr+3),*(ptr+4),




                              *(ptr+5),*(ptr+6),*(ptr+7),*(ptr+8),*(ptr+9),




                              *(ptr+10),*(ptr+11),*(ptr+12),*(ptr+13),*(ptr+14),




                              
*(ptr+15),*(ptr+16),*(ptr+17),*(ptr+18),*(ptr+19))); 




 



 

Re: Serialize/Deserialize SSL state

[Jakob Bohm via openssl-users]

On 09/08/2019 23:21, Felipe Gasper wrote:

On Aug 9, 2019, at 3:42 PM, Osama Mazahir via openssl-users 
 wrote:

Is there a way to serialize and deserialize the ssl_st state (i.e. including 
any child objects)?
  
Background: I would like to handoff all the SSL state (along my own managed state, file descriptors, etc) to another Linux running process (I will handle the IPC handoff).  The connection already had its handshake completed, app data flow had already occurred (i.e. it is not a new or early’ish context).  So, trying to see if it is possible to serialize the openssl state, shove it through a unix domain socket to the target process and then have the target process unpack the openssl state and resume IO.

For what it’s worth, I have also wished for something like this, where I could 
pass a file descriptor as well as the OpenSSL state over a socket to a separate 
process.


A possible workaround is to run the SSL code in a dedicated process
and hand around a pipe or unix domain socket carrying the plaintext.

If this is server side, the SSL process could be run under a
dedicated UID which has exclusive access to load the private key etc.,
but no access to the stored application data.

Enjoy

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

Re: Serialize/Deserialize SSL state

[Short, Todd via openssl-users]

Not without a lot of work. It’s not part of the current API.

We have tried doing an internal implementation; it was over 1K of new code, and 
it wasn’t complete.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, threeif by the Internet."

> On Aug 9, 2019, at 3:42 PM, Osama Mazahir via openssl-users 
>  wrote:
> 
> Is there a way to serialize and deserialize the ssl_st state (i.e. including 
> any child objects)?
>  
> Background: I would like to handoff all the SSL state (along my own managed 
> state, file descriptors, etc) to another Linux running process (I will handle 
> the IPC handoff).  The connection already had its handshake completed, app 
> data flow had already occurred (i.e. it is not a new or early’ish context).  
> So, trying to see if it is possible to serialize the openssl state, shove it 
> through a unix domain socket to the target process and then have the target 
> process unpack the openssl state and resume IO.



smime.p7s
Description: S/MIME cryptographic signature

Serialize/Deserialize SSL state

[Osama Mazahir via openssl-users]

Is there a way to serialize and deserialize the ssl_st state (i.e. including 
any child objects)?

Background: I would like to handoff all the SSL state (along my own managed 
state, file descriptors, etc) to another Linux running process (I will handle 
the IPC handoff).  The connection already had its handshake completed, app data 
flow had already occurred (i.e. it is not a new or early'ish context).  So, 
trying to see if it is possible to serialize the openssl state, shove it 
through a unix domain socket to the target process and then have the target 
process unpack the openssl state and resume IO.

Does BIO_read() behave differently on diff architectures?

[Venkata Veldanda via openssl-users]

Hi Experts,
I am using openssl 1.0.2 
I recently moved my app from a PPC to x86 platform (application is compiled on 
the respective platform) where I met an issue with BIO_read(). 
I read a 20bytes of data using BIO_read like following..
int    res = BIO_read(bio, buf, 20);char *ptr = buf;
The content that I send as input is a signed file content that I get from a 
different source. The issue is that the output 'buf' is not as expected on my 
x86. The behavior is different on different architectures. 
For e.g. on intel x86 platform I get the following output with additional 
0xff padded.>> For me this is not the expected result. 
22,ff82,2b,28,06,09,2a,ff86,48,ff86,fff7,0d,02,09,02,ffa0,ff82,3b,12,30
This is what I was getting on my PPC platform which is as expected with the 
same app code.22,82,2b,28,06,09,2a,86,48,86,f7,0d,02,09,02,a0,82,3b,12,30
Ofcourse, I need to further check on the source where/how the signed file was 
generated, but does anyone have any idea if BIO_read() has any specific 
handling with repsect to architectures?. I'd rule out the endianess factor as I 
would expect the entire byte order to be reversed if so. 
I print the above output using the following code. 
 INFO( STR(" ..> Header@%02d: 
%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,"                             
       "%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x",                     
ptr-buf, *(ptr+0),*(ptr+1),*(ptr+2),*(ptr+3),*(ptr+4),                          
    *(ptr+5),*(ptr+6),*(ptr+7),*(ptr+8),*(ptr+9),                              
*(ptr+10),*(ptr+11),*(ptr+12),*(ptr+13),*(ptr+14),                              
*(ptr+15),*(ptr+16),*(ptr+17),*(ptr+18),*(ptr+19))); 

Re: 1.0.2 to 1.1 migration problem with verify_callback()

[Salz, Rich via openssl-users]

> (why doesn't it use SSL_get_ex_data_X509_STORE_CTX_idx() instead of 0?).

History; OpenSSL reserved some exdata indices for itself.

Query related to obtaining of temp key

[shalu dhamija via openssl-users]

 
Hi All,

I have a query related to getting thetemporary key used during the key 
exchange. As a TLS client, I am able to getthe key using the API 
SSL_get_peer_tmp_key(). 
But when acting as TLS Server, I usedAPI SSL_get_tmp_key(). ThisAPI is 
returning the temp key for TLS1.3 ciphers but for ECDHE and DHEalgorithm type,  
the tmp key is not obtained. In the code, the tmp key is being cleared during 
the client key exchangeafter generating secrets.
Is there any other way to obtain thetemporary key when acting as a server?

Thanks in advance.

Re: OPENSSL_thread_stop() equivalent

[Salz, Rich via openssl-users]

  *   Had to downgrade the OpenSSL used in an application from 1.1.0k to 1.0.2s.

That’s too bad, given 1.0.2 is going to become unsupported at year-end.  Was it 
because the application wasn’t ready to handle opaque structures?

>Due to this I have to remove the usage of OPENSSL_thread_stop(), want to know 
>the equivalent call in OpenSSL 1.0.2s? if applicable.

1.0.2 has no concept/support for threads, so you probably don’t need to do 
anything.

Re: openssl hash value - how to generate ?

[Salz, Rich via openssl-users]

>At the bottom of the man page for x509 it states the following:
The hash algorithm used in the -subject_hash and -issuer_hash options 
before OpenSSL 1.0.0 was based on the deprecated MD5
algorithm and the encoding of the distinguished name. In OpenSSL 1.0.0 and 
later it is based on a canonical version of the DN
using SHA1.

The text isn't great.  In both cases the printed form is not what is used. 
Instead, by "canonical form" is meant the X.509 ASN1/DER encoding.

Your guess -- "I think I'm using a different string" -- is correct.

Re: OpenSSL Security Advisory

[Jakob Bohm via openssl-users]

Having reviewed the git commit for 1.1.1 I notice the following issue:

The environment variables that usually point to the secure administrator
directories (such as "Program Files") are not themselves secured, and not
intended as a secure means of obtaining these directory locations, which
are (by definition) subject to change via system configuration (initial
or later!).

There are official system library calls to obtain the actual locations
as follows:

1. If looking for the location where a program is itself installed, use
  the GetModuleFilenameW(own-hinstance) call to obtain the path to once
  own DLL or EXE.  This automatically adapts to wherever the DLL or EXE
  is copied or moved.   This is a kernel32.dll API and returns a location
  with security very close to that of the binary itself.The name
  returned is from the in-process instance of the dynamic linker.

2. If looking for the location where the running program's top level file
  (such as openssl.exe or 
some-program-loading-an-openssl-using-plugin.exe),

  use that same call but pass NULL for the hinstance parameter.

3. If looking for the system-wide secured "/etc" directory, use the
  GetSystemDirectoryW() call and append the fixed string "\\Drivers\\etc" .
  This location is permanently restricted to the system administrators and
  already contains a few traditional unix files such as "hosts". This too
  is a kernel32.dll API.  The name returned is from a system internal value
  set during OS boot.

4. If looking for the directory intended to hold system-wide configuration
  and data files, use the SHGetFolderPathW(CSIDL_COMMON_APPDATA) API from
  shfolder.dll or shell32.dll (fallback) to ask for the "all-users data
  directory", append a company/project name (such as "\\OpenSSL") and
  specify an appropriate ACL in the security argument to CreateDirectoryW()
  (if the directory doesn't already exist with a user-modified ACL,
  CreateDirectoryW will atomically detect this and return a specific error
  code in the per thread GetLastError() variable).Note that mkdir()
  only creates one level of directories per invocation and you may want
  different ACLs when creating missing parent directories.  The values
  returned by SHGetFolderPathW() are typically from one or more 
Administrator

  controlled registry keys.

Some of the above APIs may require their return value to be canonicalized
via the GetFullPathNameW() API in corner cases, retaining the result in
a global variable is advisable.

On 30/07/2019 16:27, OpenSSL wrote:

OpenSSL Security Advisory [30 July 2019]


Windows builds with insecure path defaults (CVE-2019-1552)
==



Enjoy

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

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

OpenSSL Security Advisory [30 July 2019]


Windows builds with insecure path defaults (CVE-2019-1552)
==

Severity: Low

OpenSSL has internal defaults for a directory tree where it can find a
configuration file as well as certificates used for verification in
TLS.  This directory is most commonly referred to as OPENSSLDIR, and
is configurable with the --prefix / --openssldir configuration options.

For OpenSSL versions 1.1.0 and 1.1.1, the mingw configuration targets
assume that resulting programs and libraries are installed in a
Unix-like environment and the default prefix for program installation
as well as for OPENSSLDIR should be '/usr/local'.

However, mingw programs are Windows programs, and as such, find
themselves looking at sub-directories of 'C:/usr/local', which may be
world writable, which enables untrusted users to modify OpenSSL's
default configuration, insert CA certificates, modify (or even
replace) existing engine modules, etc.

For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR
on all Unix and Windows targets, including Visual C builds.  However,
some build instructions for the diverse Windows targets on 1.0.2
encourage you to specify your own --prefix.

OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue.
Due to the limited scope of affected deployments this has been
assessed as low severity and therefore we are not creating new
releases at this time.

The mitigations are found in these commits:
- - For 1.1.1, commit 54aa9d51b09d67e90db443f682cface795f5af9e
- - For 1.1.0, commit e32bc855a81a2d48d215c506bdeb4f598045f7e9 and
  b15a19c148384e73338aa7c5b12652138e35ed28
- - For 1.0.2, commit d333ebaf9c77332754a9d5e111e2f53e1de54fdd

The 1.1.1 and 1.1.0 mitigation set more appropriate defaults for
mingw, while the 1.0.2 mitigation documents the issue and provides
enhanced examples.

This issue was reported by Rich Mirth.  The fix was developed by
Richard Levitte from the OpenSSL development team.  It was reported to
OpenSSL on 9th Jun 2019.

Note
=

OpenSSL 1.0.2 and 1.1.0 are currently only receiving security updates.
Support for 1.0.2 will end on 31st December 2019. Support for 1.1.0
will end on 11th September 2019. Users of these versions should
upgrade to OpenSSL 1.1.1.


Referenses
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20190730.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-

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl1AU3sACgkQ1enkP335
7oxnEw//ebb9FK16oXpvW6nifNgSHUBYRaq+3ApvSfGG8Er1M0Zn80iD/WY8wzM7
ZabUUNlOdnOs0iQivMYzy+8QzP9NRaqX2WZk/Q1koNT5WAt9+VDCw6hhbp6FN8B9
9aeRvdawNME9JPysl3KOR6DnYJQnpJgV0yQ2pJM2yMKNuDFkvy6E9ieMoWAGx5Ya
8JZ4KGFubA1vDPj5xowkRDxZo+SLdAaEMQw0YG8DWSK5BViZV+3d4OMAAL1RjnZy
s4OSghqi7wUbgo8XO38/roN4y4BEgmEXU0IpSRNf1xrwCoFM82hEgOO3xWxPtbZk
EtDcMUTtMYa1g5IMdGIkVvS4wnNr2j2BAi8WECkPf5QCzCoaX/Xc9jutslTw20M/
UoZnyGgVoOQCsO6ECwLUnSEp772mhS1056c4OKb62kfhlIcGkWi5vk5wjWVZFxEx
rXJC7xabp29e051mnrJtLr85UWUv5B/ywREPyvbdjWg6lJBxB0dOYXMQLpJi6B5i
/bDX7czP/1EeOg+FDSGOR174JGIyMYmPqpyzGpdds72GfOQqtGHC2z41FlvHMglB
9VobSZnF97MIan4/9H4ge+gUUq0PeIZ+invvgCHzuW4oYBOngwwVD5QXfSQUjA9a
etYHkJx+3t4hPrPKAT/J0jHA7AbWtYK7dL6qTxSwli2Gl/D4ipk=
=gxli
-END PGP SIGNATURE-

Re: Openssl binary with statically linked libssl and libcrypto

[Salz, Rich via openssl-users]

>Sadly, I can not make use of the "no-shared" option as I still need the
shared libraries to be built.
  
Statically linking against files built for shared libraries is possible on many 
platforms (link against the .a even though .so exists), but not all platforms.

You can always build twice.

Re: help - building OpenSSL fips for 64 bit Android

[Salz, Rich via openssl-users]

>that the setenv-android.sh script doesn't account for 64 bit architectures.

Correct.  The current FIPS module has not been modified for quite some time, 
and your platform is not supported.

If you cannot follow the steps *exactly* you cannot claim FIPS validation.  The 
OpenSSL project is working on a new FIPS validation for the next release, but 
it will only support a few platforms (those of the sponsors funding the work, 
mainly).  Whichever release you use, you will have to hire a lab to get your 
own validation, or hope that a vendor provides one.

s_server configuration

[Steven Madwin via openssl-users]

Hi All,

 

I’m trying to get an OCSP server operating in an SSL (really TLS1.2) 
environment. It works fine in the HTTP world, but I’m having issues with 
getting s_server to handle the communication in the Secure HTTPS world.

 

If anyone has any suggestions to get the connection to persist I’d be VERY 
appreciative!

 

This is what I’m seeing:

 

--- Using OpenSSL v1.1.1c to enable TLS on Port 8902 ---

 

C:\OpenSSL-Win64\bin>openssl  s_server -port 8902 -4 -certform PEM -cert 
"C:\OpenSSL-Win64\bin\PEM\test.cer" -cert_chain 
C:\OpenSSL-Win64\bin\PEM\DigiCertTrustChain.cer -keyform PEM -pass 
pass:password -key "C:\OpenSSL-Win64\bin\PEM\test_key.pem"  -status_verbose

 

Using default temp DH parameters

ACCEPT

 

cert_status: callback called

cert_status: AIA URL: http://ocsp.digicert.com

cert_status: Can't retrieve issuer certificate.

-BEGIN SSL SESSION PARAMETERS-

MFoCAQECAgMDBALAMAQABDBt6uS6sCfohxxHvmv7hPIXRbjKzDqNJqoCpymZR1qc

CpGHf1mBjQ5/B32R7/aXl8mhBgIEXS0L6KIEAgIcIKQGBAQBrQMCAQE=

-END SSL SESSION PARAMETERS-

Shared 
ciphers:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA

Signature Algorithms: 
RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512

Shared Signature Algorithms: 
RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512

Supported Elliptic Curve Point Formats: uncompressed

Supported Elliptic Groups: X25519:P-256:P-384

Shared Elliptic groups: X25519:P-256:P-384

---

No server certificate CA names sent

CIPHER is ECDHE-RSA-AES256-GCM-SHA384

Secure Renegotiation IS supported

POST / HTTP/1.1

Accept: */*

Content-Type: application/ocsp-request

Content-Length: 143

Character-Encoding: binary

User-Agent: PPKHandler

Host: gemma.adobe.com:8902

Connection: Keep-Alive

Cache-Control: no-cache

Cookie: AAMC_adobe_0=REGION%7C9; s_nr=1562971576381-Repeat; 
adcloud={%22_les_v%22:%22y%2Cadobe.com%2C1564005807%22}; 
AMCV_9E1005A551ED61CA0A490D45%40AdobeOrg=-1303530583%7CMCAID%7C2D05BCDE05032D0E-40001185A003F0F0%7CMCMID%7C06088709957453939181689303953590820094%7CMCAAMLH-1563576332%7C9%7CMCAAMB-1563576332%7Cj8Odv6LonN4r3an7LhD3WZrU1bUpAkFkkiY1ncBR96t2PTI%7CMCOPTOUT-1562978727s%7CNONE%7CvVersion%7C3.3.0%7CMCIDTS%7C18072%7CMCSYNCSOP%7C411-18079%7CMCCIDH%7C1521286796;
 
mbox=PC#ddd404f9c1d0418ba9692aaf983e9e03.28_36#1626216329|session#7b3f3fbfb1504526acdb639358290766#1562973437;
 s_vi=[CS]v1|2D05BCDE05032D0E-40001185A003F0F0[CE]; 
_fbp=fb.1.1561413807767.1078876052

 

0
 +00­ +0[1]

  _  


  _  

ƒ°â█g┘⌐├Z<₧é╚ @ERROR

shutting down SSL

CONNECTION CLOSED

 

 




 

Steven Madwin

Software PKI Engineer

Adobe Inc.

345 Park Avenue, MS-W15

San Jose, CA 95110-2704 USA

Phone:   408.536.4343

Fax: 408.536.6024

 <mailto:steven.mad...@adobe.com> steven.mad...@adobe.com

 

 



smime.p7s
Description: S/MIME cryptographic signature

What's up with ectest?

[Salz, Rich via openssl-users]

Ectest has been broken for quite some time.  What are the plans to get it fixed?

Re: looks like the support for Heart beat extension is removed from openssl

[Salz, Rich via openssl-users]

  *   Why the support for Heart beat extension is removed from openssl.

It’s intended use was to check MTU along the path.  That is not very useful any 
more.



  *   How to handle abnormal disconnection in DTLS？

You should be able to detect time-outs and “failure to close” in your 
application.

Re: Will my application be FIPS 140-2 Certified under following conditions?

[Salz, Rich via openssl-users]

> It seems to me that the easiest thing to do is maintain that release of 
OpenSSL by themselves.

>Which would be another variation of such unofficial work.
  
You could look at things like that.  I consider it to be more like "your free 
FIPS ride is done, time to pay up"

>That policy page is half the problem, the other half being the decision
not to make a FIPS module for the current 1.1.x series.
  
There are many problems with the current FOM.  One notable example, is that you 
cannot have a single executable that handles both FIPS and non-FIPS TLS 
connections at the same time.  Another is the way the whole integrity check is 
done. I could go on and on, but won't.  The project spent a long time 
discussing and considering alternatives and decided a new start was the best 
way to move forwards. It was a carefully-considered decision.  The fact that it 
"left a coverage gap" in FIPS/1.0.2 was also discussed.

It's too bad not everyone is pleased. Probably those who didn't plan well, 
and/or who just got "FIPS for free" and expected that to last forever seem to 
be among those particular unhappy. Speaking for myself, AND NOT THE PROJECT, 
too bad.

Re: Will my application be FIPS 140-2 Certified under following conditions?

[Jakob Bohm via openssl-users]

On 08/07/2019 10:12, Dr Paul Dale wrote:
I have to disagree with the “decision not to make a FIPS module for 
the current 1.1.x series” comment.  Technically, this is true.  More 
practically, 3.0 is intended to be source compatible with 1.1.x.  Thus 
far, nothing should be broken in this respect.



The key word is "intended".

If support for 1.0.2 is required beyond the end of this year, it is 
available: https://www.openssl.org/support/contracts.html



I am unsure if this is an affordable route for all affected users
and distributions (especially non-profit OS distributions).



I’d also be interested to know what is wrong with the policy page?



Only that it states the policy of stopping 1.0.2 support at end of
2019, which would be fine if a FIPS-capable replacement had been
ready by now (as is fortunately the case for non-FIPS).

Enjoy

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

Re: Will my application be FIPS 140-2 Certified under following conditions?

[Jakob Bohm via openssl-users]

On 06/07/2019 16:30, Salz, Rich wrote:


 >> They would have to get their own validation, their own lab to verify, 
etc., etc.

That seems to contradict the other answer, which is that legally, the
FIPS cannister (properly built) can be used with any software outside
the cryptographic boundary, the soon-to-be-deprecated OpenSSL 1.0.2
library just being the normal default.
   
You are correct.  My statement, which was technically incorrect, is more likely to be realistic :)
   

The point is that some people may soon be in a desperate need to find a

 FIPS-capable replacement for OpenSSL 1.0.x.
   
It seems to me that the easiest thing to do is maintain that release of OpenSSL by themselves.


Which would be another variation of such unofficial work.



If someone is thinking of fitting OpenSSL 1.1.x to become a user of the 
existing FOM, then they will probably find it easier to, well, just maintain 
what currently works.

Just because something is past "end of life" does not mean that anyone's 
ability to use it is revoked.  It just means that keeping it working is their 
responsibility.  Anyone can use the FOM until it expires (sunsets is the term used), 
which lasts one year beyond 1.0.2 as I recall.  See 
https://www.openssl.org/blog/blog/2018/05/18/new-lts/ for some more information on this.




That policy page is half the problem, the other half being the decision
not to make a FIPS module for the current 1.1.x series.


Enjoy

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

Re: Will my application be FIPS 140-2 Certified under following conditions?

[Salz, Rich via openssl-users]

>> They would have to get their own validation, their own lab to verify, 
etc., etc.
>That seems to contradict the other answer, which is that legally, the
>FIPS cannister (properly built) can be used with any software outside
>the cryptographic boundary, the soon-to-be-deprecated OpenSSL 1.0.2
>library just being the normal default.
  
You are correct.  My statement, which was technically incorrect, is more likely 
to be realistic :)
  
>The point is that some people may soon be in a desperate need to find a
FIPS-capable replacement for OpenSSL 1.0.x.
  
It seems to me that the easiest thing to do is maintain that release of OpenSSL 
by themselves.

If someone is thinking of fitting OpenSSL 1.1.x to become a user of the 
existing FOM, then they will probably find it easier to, well, just maintain 
what currently works.

Just because something is past "end of life" does not mean that anyone's 
ability to use it is revoked.  It just means that keeping it working is their 
responsibility.  Anyone can use the FOM until it expires (sunsets is the term 
used), which lasts one year beyond 1.0.2 as I recall.  See 
https://www.openssl.org/blog/blog/2018/05/18/new-lts/ for some more information 
on this.

Re: Will my application be FIPS 140-2 Certified under following conditions?

[Salz, Rich via openssl-users]

>Is the use of OpenSSL an actual legal requirement of the certification of
the FIPS object module, or just the easiest way to use it?
  
I'm not sure who you are asking this.

The exiting FIPS validations for OpenSSL only cover the 1.0.2 based source code.
  
>Difference would be particularly significant in case someone created code
to use the validated FOM 2.0 module with the OpenSSL 1.1.x feature
enhancements (as the project itself has indicated no desire to do so).
  
They would have to get their own validation, their own lab to verify, etc., etc.

Re: Will my application be FIPS 140-2 Certified under following conditions?

[Jakob Bohm via openssl-users]

Is the use of OpenSSL an actual legal requirement of the certification of
the FIPS object module, or just the easiest way to use it?

Difference would be particularly significant in case someone created code
to use the validated FOM 2.0 module with the OpenSSL 1.1.x feature
enhancements (as the project itself has indicated no desire to do so).

On 04/07/2019 04:09, Kyle Hamilton wrote:
Also, on question b: No.  You need to build a compatible version of 
openssl as specified in the User Guide, and link that version.  
FIPS_mode_set() tells the library to always and only use the 
implementations in the FIPS canister; the canister does not replace 
the library entirely.


-Kyle H

On Wed, Jul 3, 2019, 11:55 Dipak B <mailto:deepak.red...@gmail.com>> wrote:


Dear Experts,

Can you please help me with the following question?

My win32 desktop application uses 'libcurl' to interact with web
service, in order to get my application FIPS 140-2 certified,
following is the plan which I arrived at after going through the
'User Guide' and 'Security Policy' pdfs.

Plan:
a. After verifying HMAC-SHA1 of openssl-fips-2.0.16.tar.gz, build
it to generate fipscanister.lib (FOM) as windows static library.
b. Build libcurl as windows static library using above
fipscanister.lib
c. Link my desktop application with above libcurl.lib after adding
FIPS_mode_set()

Questions:
a. On following points a, b,c, can I confirm that my application
is FIPS 140-2 certified?
b.  fipscanister.lib is always static library and it can be
substituted for libssl.lib / ssleay.lib?

configuring openssl-1.1.1b with -DOPENSSL_TLS_SECURITY_LEVEL=0

[syed moulana via openssl-users]

Hi
Are we expect to loose the TLS_1.3 security capability if we configure the 
openssl-1.1.1b security level to -DOPENSSL_TLS_SECURITY_LEVEL=0 ?orin other 
words, does it makes TLS_1.3 backwards compatible ?orwe are not using TLS_1.3  
if we configure like this.
ThanksSyed

Re: Can applications built with 'FIPS Capable OpenSSL' be called as 'FIPS 140-2' certified?

[Salz, Rich via openssl-users]

Didn’t you just ask this question? :)

If you followed the Win32 build instructions *exactly* and you build your 
application to turn on FIPS mode and link against the canister, then yes.

If you made changes to the process, then no.

Re: openssl-fips configure parameters to force IANA cipher suite compliance

[Jakob Bohm via openssl-users]

On 02/07/2019 22:13, Larry Jordan via openssl-users wrote:


I want to build an openssl-fips canister to force IANA cipher suite 
compliance.


With the help of an openssl-iana mapping 
(https://testssl.sh/openssl-iana.mapping.html) I can identify the 
corresponding OpenSSL cipher suites.



Not sure what you mean?  To my knowledge IANA doesn't (and has no authority
to) define TLS compliance requirements.  They merely keep a database of
various numbers and names assigned in Internet standards ("Internet Assigned
Numbers Authority").

And the openssl-fips canister is a very specific, legally defined exact 
binary

that has gone through expensive US-government tests to allow use by said US
government, with absolutely no changes permitted, even to fix security bugs!

Now it so happens that since long before there were any Internet standards
for SSL/TLS, the OpenSSL/SSLeay family of libraries have used slightly
different names for the numbered cipher suites, especially the ones that
existed before official IETF standards were established.

The key spelling differences obviously being:

1. OpenSSL doesn't put TLS_ in front and _WITH_ in the middle of all the
  names, because that just gets in the way when administrators type in
  configuration changes on their servers.

2. OpenSSL uses dash, not underscore.

3. Because it was the historic default, OpenSSL lets you omit the "RSA_" and
  CBC_ in those cipher suite names.

4. OpenSSL omits the _ or - between AES and the bit count, just like IETF
  already does with SHA.

5. For triple-DES (once the strongest common algorithm, and thus still
  needed to talk to older systems), OpenSSL historically considered it a
  variant of the CBC mode for DES, not a variant of DES for CBC mode.
   Thus the oldest 3DES_CBC cipher suites use DES-CBC3 in their names,
  while the new ones follow IETF naming.  Similarly, DHE_ is spelled EDH-
  in older suites.

6. Whatever user interface a program runs on top of OpenSSL can display the
  names however it wants.

7. If a program wants to map the IETF names to the OpenSSL names, it can
  probably start by doing the string substitutions in differences 1 to 4
  above, then add some special cases for things like
 TLS_DHE_RSA_WITH_3DES_CBC_SHA maps via rules to
     DHE-RSA-3DES-CBC-SHA which maps via special case lookup to
 EDH-RSA-DES-CBC3-SHA

8. To be absolutely sure you handle all known cases, you have to find the
  OpenSSL source file that defines the names and check it against the IANA
  database of cipher suite numbers from IETF standards and non-IETF 
extensions

  (Such as Camelia and GOST cipher suites).



IANA OpenSSL

TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246 [0x2f] AES128-SHA

TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 [0x3c] 
AES128-SHA256


TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246 [0x3d] 
AES256-SHA256


TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 [0x9d] 
AES256-GCM-SHA384


TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246 [0x67] 
DHE-RSA-AES128-SHA256


TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246 [0x6b] 
DHE-RSA-AES256-SHA256


TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288 [0x9f] 
DHE-RSA-AES256-GCM-SHA384


TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 
5289   [0xc023] ECDHE-ECDSA-AES128-SHA256


TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 
5289 [0xc02b] ECDHE-ECDSA-AES128-GCM-SHA256


TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 
5289   [0xc024] ECDHE-ECDSA-AES256-SHA384


TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 
5289 [0xc02c] ECDHE-ECDSA-AES256-GCM-SHA384


TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289 [0xc027] 
ECDHE-RSA-AES128-SHA256


TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 
5289  [0xc02f] ECDHE-RSA-AES128-GCM-SHA256


TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289 [0xc028] 
ECDHE-RSA-AES256-SHA384


TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 
5289  [0xc030] ECDHE-RSA-AES256-GCM-SHA384


How would I configure openssl-fips to force this precise compliance, 
eliminating all other cipher suites?


Thank you.

--Larry

C++ Developer




Enjoy

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

openssl-fips configure parameters to force IANA cipher suite compliance

[Larry Jordan via openssl-users]

I want to build an openssl-fips canister to force IANA cipher suite compliance.

With the help of an openssl-iana mapping 
(https://testssl.sh/openssl-iana.mapping.html) I can identify the corresponding 
OpenSSL cipher suites.

IANA

 OpenSSL
TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 5246 
  [0x2f] AES128-SHA
TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246  
  [0x3c] AES128-SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246  
  [0x3d] AES256-SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288  
[0x9d] AES256-GCM-SHA384

TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246  
   [0x67] DHE-RSA-AES128-SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246  
   [0x6b] DHE-RSA-AES256-SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288  
 [0x9f] DHE-RSA-AES256-GCM-SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289  
 [0xc023] ECDHE-ECDSA-AES128-SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289  
   [0xc02b] ECDHE-ECDSA-AES128-GCM-SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289  
 [0xc024] ECDHE-ECDSA-AES256-SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289  
   [0xc02c] ECDHE-ECDSA-AES256-GCM-SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
[0xc027] ECDHE-RSA-AES128-SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
  [0xc02f] ECDHE-RSA-AES128-GCM-SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
[0xc028] ECDHE-RSA-AES256-SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
  [0xc030] ECDHE-RSA-AES256-GCM-SHA384

How would I configure openssl-fips to force this precise compliance, 
eliminating all other cipher suites?

Thank you.

--Larry
C++ Developer

Re: Building a DER sequence

[Salz, Rich via openssl-users]

>I see those macros, but ... is there any documentation?
  
No.
 

Re: error: dereferencing pointer to incomplete type DH {aka struct dh_st}

[Salz, Rich via openssl-users]

>I'm attempting to build our RHEL 7 based product on RHEL 8 and running 
> into a lot of changes from openssl 1.0.2k-fips (RHEL 7) to 1.1.1 FIPS (RHEL 
> 8).  I haven't found a good guide to adapting the sources to these changes.

Web search for "openssl opaque accessors" turns up many hits; these two seem 
useful:
  
https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes
http://vega.pgw.jp/~kabe/vsd/migrate2openssl-1.1.html 
 
PS: A long confidential email disclaimer is silly, particularly when posting to 
a large public mailing list. :)

Re: Building a DER sequence

[Salz, Rich via openssl-users]

Do I construct a sequence and add items to it - top down?

No, because then you have to go back and patch the sequence length and perhaps 
slide everything up or down a copule of bytes.

I would look at an existing simple sequence and start writing your own based on 
that; look for ASN1_SEQUENCE macros in crypto/x509/x*.c files.  Another set of 
macros will declare the i2d/d2i and PEM functions if needed.

Using openssl test

[syed moulana via openssl-users]

Hi Is there any test application scripts  bundled with openssl_1.1.1b ? If yes. 
 How to compile it.Is it possible use that test application to verify SSL 
handshake ?

Thank youSyed
Sent from Yahoo Mail on Android

Re: Proposal to remove some platforms

[Salz, Rich via openssl-users]

>Yes NetBSD cares about PARISC... We still build and run on it.

Thanks.  The targets removed in that PR were for hpux-parisc.

openssl-1.1.1b: Compilation errors when use async and ct

[Samiya Khanum via openssl-users]

Hi,

While compiling async I see below errors with UCLIBC.



*libcrypto.so: undefined reference to `getcontext'libcrypto.so: undefined
reference to `setcontext'libcrypto.so: undefined reference to `makecontext'*

As UCLIBC doesn't have support to these APIs, i have added no-async in
configure. With no-async below errors are seen.




*libcrypto.so: undefined reference to `ERR_load_ASYNC_strings'libcrypto.so:
undefined reference to `async_init'libcrypto.so: undefined reference to
`async_delete_thread_state'libcrypto.so: undefined reference to
`async_deinit'*

Do we need to have macro check" #ifndef OPENSSL_NO_ASYNC" before these api
calls?

Similarly for CT, we are seeing below errors. With no-ct options,
compilation is OK.

We would like to know what would be the impact if we disable async and ct
features. Could you please help us in understanding these features.

In file included from ../../../../vendor/openssl/crypto/ct/ct_b64.c:17:0:
../../../../vendor/openssl/crypto/ct/ct_locl.h:58:5: error: unknown type
name 'sct_version_t'
 sct_version_t version;
 ^
../../../../vendor/openssl/crypto/ct/ct_locl.h:78:5: error: unknown type
name 'ct_log_entry_type_t'
 ct_log_entry_type_t entry_type;
 ^
../../../../vendor/openssl/crypto/ct/ct_locl.h:80:5: error: unknown type
name 'sct_source_t'
 sct_source_t source;
 ^
../../../../vendor/openssl/crypto/ct/ct_locl.h:82:5: error: unknown type
name 'sct_validation_status_t'
 sct_validation_status_t validation_status;
 ^
In file included from ../../../../vendor/openssl/crypto/ct/ct_b64.c:14:0:
../../../../vendor/openssl/crypto/ct/ct_b64.c: In function
'ct_base64_decode':
../../../../vendor/openssl/crypto/ct/ct_b64.c:38:15: error:
'CT_F_CT_BASE64_DECODE' undeclared (first use in this function)
 CTerr(CT_F_CT_BASE64_DECODE, ERR_R_MALLOC_FAILURE);
   ^
../../../../vendor/openssl/include/openssl/err.h:29:59: note: in definition
of macro 'ERR_PUT_error'
 #  define ERR_PUT_error(a,b,c,d,e)ERR_put_error(a,b,c,d,e)
   ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:38:9: note: in expansion of
macro 'CTerr'
 CTerr(CT_F_CT_BASE64_DECODE, ERR_R_MALLOC_FAILURE);
 ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:38:15: note: each undeclared
identifier is reported only once for each function it appears in
 CTerr(CT_F_CT_BASE64_DECODE, ERR_R_MALLOC_FAILURE);
   ^
../../../../vendor/openssl/include/openssl/err.h:29:59: note: in definition
of macro 'ERR_PUT_error'
 #  define ERR_PUT_error(a,b,c,d,e)ERR_put_error(a,b,c,d,e)
   ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:38:9: note: in expansion of
macro 'CTerr'
 CTerr(CT_F_CT_BASE64_DECODE, ERR_R_MALLOC_FAILURE);
 ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:44:38: error:
'CT_R_BASE64_DECODE_ERROR' undeclared (first use in this function)
 CTerr(CT_F_CT_BASE64_DECODE, CT_R_BASE64_DECODE_ERROR);
  ^
../../../../vendor/openssl/include/openssl/err.h:29:61: note: in definition
of macro 'ERR_PUT_error'
 #  define ERR_PUT_error(a,b,c,d,e)ERR_put_error(a,b,c,d,e)
 ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:44:9: note: in expansion of
macro 'CTerr'
 CTerr(CT_F_CT_BASE64_DECODE, CT_R_BASE64_DECODE_ERROR);
 ^
../../../../vendor/openssl/crypto/ct/ct_b64.c: At top level:
../../../../vendor/openssl/crypto/ct/ct_b64.c:64:26: error: unknown type
name 'ct_log_entry_type_t'
  ct_log_entry_type_t entry_type, uint64_t
timestamp,
  ^
In file included from ../../../../vendor/openssl/crypto/ct/ct_b64.c:14:0:
../../../../vendor/openssl/crypto/ct/ct_b64.c: In function
'CTLOG_new_from_base64':
../../../../vendor/openssl/crypto/ct/ct_b64.c:143:15: error:
'CT_F_CTLOG_NEW_FROM_BASE64' undeclared (first use in this function)
 CTerr(CT_F_CTLOG_NEW_FROM_BASE64, ERR_R_PASSED_INVALID_ARGUMENT);
   ^
../../../../vendor/openssl/include/openssl/err.h:29:59: note: in definition
of macro 'ERR_PUT_error'
 #  define ERR_PUT_error(a,b,c,d,e)ERR_put_error(a,b,c,d,e)
   ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:143:9: note: in expansion of
macro 'CTerr'
 CTerr(CT_F_CTLOG_NEW_FROM_BASE64, ERR_R_PASSED_INVALID_ARGUMENT);
 ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:149:43: error:
'CT_R_LOG_CONF_INVALID_KEY' undeclared (first use in this function)
 CTerr(CT_F_CTLOG_NEW_FROM_BASE64, CT_R_LOG_CONF_INVALID_KEY);
   ^
../../../../vendor/openssl/include/openssl/err.h:29:61: note: in definition
of macro 'ERR_PUT_error'
 #  define ERR_PUT_error(a,b,c,d,e)ERR_put_error

How to handle servername indication with openssl library from server

[DonCorleone via openssl-users]

I've develepted some windows server side socket in c
and want to add sni server name indication to support sni

but servername callback never called and cant get servername
is there any suggestion?

I've defined some functions for initializing ssl before main function:

    void init_openssl()
    {
        SSL_load_error_strings();
        OpenSSL_add_ssl_algorithms();
    }
    
    SSL_CTX *create_context()
    {
        const SSL_METHOD *method;
        SSL_CTX *ctx;
    
        //method = SSLv23_server_method();
        method = TLSv1_1_server_method();
    
        ctx = SSL_CTX_new(method);
        if (!ctx) {
            perror("Unable to create SSL context");
            ERR_print_errors_fp(stderr);
            exit(EXIT_FAILURE);
        }
    
        return ctx;
    }
    
    void configure_context(SSL_CTX *ctx)
    {
        
        SSL_CTX_set_ecdh_auto(ctx, 1);
    
        /* Set the key and cert */
        if (SSL_CTX_use_certificate_file(ctx, "somesite.cer", SSL_FILETYPE_PEM) 
<= 0) {
            ERR_print_errors_fp(stderr);
    
            exit(EXIT_FAILURE);
        }
    
        if (SSL_CTX_use_PrivateKey_file(ctx, "key.pem", SSL_FILETYPE_PEM) <= 0) 
{
            ERR_print_errors_fp(stderr);
    
            exit(EXIT_FAILURE);
        }
    }
    
    static int ssl_servername_cb(SSL *ssl, int *ad, void *arg)
    {
        if (ssl == NULL)
            return SSL_TLSEXT_ERR_NOACK;
    
        const char* servername = SSL_get_servername(ssl, 
TLSEXT_NAMETYPE_host_name);
        printf("ServerName: %s\n", servername);
    }
    

and here is my main function: 

    int main()
    {
    
    SSL_CTX *ctx;
    
        init_openssl();
        ctx = create_context();
    
        configure_context(ctx);
        
        SSL_CTX_set_tlsext_servername_callback(ctx, ssl_servername_cb);
        
    
    
        WSADATA wsaData;
        int iResult;
    
        SOCKET ListenSocket = INVALID_SOCKET;
        SOCKET ClientSocket = INVALID_SOCKET;
    
        struct addrinfo *result = NULL;
        struct addrinfo hints;
    
        int iSendResult;
        char recvbuf[DEFAULT_BUFLEN];
        int recvbuflen = DEFAULT_BUFLEN;
    
        // Initialize Winsock
        iResult = WSAStartup(MAKEWORD(2, 2), );
        if (iResult != 0) {
            printf("WSAStartup failed with error: %d\n", iResult);
            return 1;
        }
    
        ZeroMemory(, sizeof(hints));
        hints.ai_family = AF_INET;
        hints.ai_socktype = SOCK_STREAM;
        hints.ai_protocol = IPPROTO_TCP;
        hints.ai_flags = AI_PASSIVE;
    
        // Resolve the server address and port
        //iResult = getaddrinfo(NULL, DEFAULT_PORT, , );
        iResult = getaddrinfo("192.168.200.1", DEFAULT_PORT, , );
        //iResult = getaddrinfo("127.0.0.1", DEFAULT_PORT, , );
        
        if (iResult != 0) {
            printf("getaddrinfo failed with error: %d\n", iResult);
            WSACleanup();
            return 1;
        }
    
        // Create a SOCKET for connecting to server    
        ListenSocket = socket(result->ai_family, result->ai_socktype, 
result->ai_protocol);
        if (ListenSocket == INVALID_SOCKET) {
            printf("socket failed with error: %ld\n", WSAGetLastError());
            freeaddrinfo(result);
            WSACleanup();
            return 1;
        }
    
        // Setup the TCP listening socket    
        iResult = bind(ListenSocket, result->ai_addr, (int)result->ai_addrlen);
        if (iResult == SOCKET_ERROR) {
            printf("bind failed with error: %d\n", WSAGetLastError());
            freeaddrinfo(result);
            closesocket(ListenSocket);
            WSACleanup();
            return 1;
        }
    
        freeaddrinfo(result);
    
        iResult = listen(ListenSocket, SOMAXCONN);
        if (iResult == SOCKET_ERROR) {
            printf("listen failed with error: %d\n", WSAGetLastError());
            closesocket(ListenSocket);
            WSACleanup();
            return 1;
        }
    
        // Accept a client socket        
        ClientSocket = accept(ListenSocket, NULL, NULL);    
        SSL *ssl;
        
        if (ClientSocket == INVALID_SOCKET) {
            printf("accept failed with error: %d\n", WSAGetLastError());
            closesocket(ListenSocket);
            WSACleanup();
            return 1;
        }
    
        // No longer need server socket
        closesocket(ListenSocket);
    
        // Receive until the peer shuts down the connection
        do {
            
            ssl = SSL_new(ctx);
            SSL_set_fd(ssl, ListenSocket);
            //int rr = SSL_accept(ssl);
    
            iResult = recv(ClientSocket, recvbuf, recvbuflen, 0);
            
            //int type=SSL_get_servername_type(ssl);
            //const char[] x=SSL_get_servername(ssl, type);
            //const char *zx= SSL_get_servername(ssl, 
TLSEXT_NAMETYPE_host_name);
            
            if (iResult > 0) {
        

Re: Make file removed in openssl 1.1.1

[Salz, Rich via openssl-users]

>It depends on what you want to achieve. The top level template Makefile is 
> in
Configureations/unix-Makefile.tmpl. Each individual directory contains a
build.info file which allows you to make per-directory changes to things 
like
the sources to be compiled, etc.
  
And also important, these are all processed to build a single Makefile.  
There's only one now.

Re: failing in reproducing .so files

[Salz, Rich via openssl-users]

If you are adding new functions to the library, you need to
1A   Make sure there is a prototype in one of the existing OpenSSL 
header files;
OR
1B   If your prototype is in a new header file, you will have to edit 
Configurations/unix-Makefile.tmpl to pick up that file.

2  Run configure

3.Do “make update”  Verify that the previous steps worked by 
looking for your new function(s) being declared in util/libcrypto.num

4.Run make

This could be documented somewhere; anyone want to copy this email into a new 
issue?

Re: New to the list and one question ;-)

[Patrick Regnouf via openssl-users]

Thanks Matt, adding a call to SSL_CTX_set_ecdh_auto()  on the server side 
actually did the trick. Problem solved!!!
/Patrick 



Contrary to what you said in your original post the chrome session is NOT
selecting 0xc02f. Instead it is selecting 0x002f which is
TLS_RSA_WITH_AES_128_CBC_SHA (aka AES128-SHA in the OpenSSL naming scheme).

This cipher is not being offered by firefox but is by chrome. It is striking to
note that although chrome is offering a whole list of ciphersuites offering
forward secrecy (i.e. all those including ECDHE/DHE), the server is instead
selecting a very old ciphersuite that does not support forward secrecy.

In comparison firefox does not offer any ciphersuites that do not support
forward secrecy and the connection fails.

Have you called SSL_CTX_set_tmp_dh() or SSL_CTX_set_ecdh_auto() on the server?
I'd suggest trying those and see if it helps.

Matt


Sent from Yahoo Mail for iPhone

Re: New to the list and one question ;-)

[Patrick Regnouf via openssl-users]

As requested here are two captures attached: one successfully handshakes with 
the server (chrome)  and one fails the handshake (firefox).
I would be very grateful if anyone could shed some light on this.

the openssl version which is linked to my server/relay program is 1.0.2s

Thanks

/Patrick




On Mon, 2019-06-10 at 13:41 -0400, Viktor Dukhovni wrote:On Mon, Jun 10, 2019 
at 03:21:16PM +, Patrick Regnouf via openssl-users wrote:
> 
> > All is well and good when the program works on the linux PC and the
> > handshake is succesful using the 0xc02f cipher. and that is linked to
> > version 3.0.0 of openssl.  on the embedded version, (linked with version
> > 1.0.2s) firefox fails the handshake with ssl_no_shared_cipher whereas
> > chrome and safari do successfully handshake chrome client hello contains
> > 12 ciphers and the server hello seems to choose 0xc02f cipher firefox
> > client hello contains only 10 ciphers (including the above mentioned 0xc02f
> > cipher) and fails.  any suggestion as to what could causes that failure
> > would be appreciated.
> 
> In addition to the cipher algorithm, the two parties must also agree
> on the signature algorithms, supported EC groups, ...
> 
> You've not provided much detail about the configuration of the
> embedded (1.0.2s) server.  The cipher that works with the other
> browsers is:
> 
> 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA  
>Enc=AESGCM(128) Mac=AEAD
> 
> this requires a shared ECDHE curve, are you using "auto", or an
> explicit curve?  What are the signature algorithms on your certificate
> chain?
> 
> It would also be useful to post PCAP files of a working handshake
> with Chrome, and a failing handshake with Firefox.


chrome_success.pcap
Description: application/vnd.tcpdump.pcap


firefox_fail.pcap
Description: application/vnd.tcpdump.pcap

Re: TLSv12 Client Certificate Selection Behavior !!

[Jakob Bohm via openssl-users]

On 11/06/2019 19:21, Viktor Dukhovni wrote:

On Jun 11, 2019, at 1:02 PM, Michael Wojcik  
wrote:

And, of course, there are no doubt still people out there running internal CAs 
that generate X.509v1 certs, which won't have any extensions at all. No KU, no 
EKU, no SAN, no SKID/AKID ... Presumably a check for proper KU on the client 
certificate would be bypassed if the client cert is v1 - but then using a v1 
certificate is another violation of RFC 5246 (7.4.2) that OpenSSL probably 
should not enforce.

Yes, v1 certs would get a free ride.  The reason to enforce KU
in client certs would be that client certs are not infrequently
(though not always) optional, and it can be better to not send
any client cert, than to send one the server will reject.

RSA client certs without digital signature in KU are increasingly
not interoperable as more server implementations are checking the
keyUsage these days.  So at some point it makes sense to consider
not offering such (client) certs to the peer server.

But at the end of the day, the user should not have configured
such a client cert in the first place, so it may also make sense
to just leave the responsibility with the user.


Note that the most common variant of encrypt-only RSA client certs
is probably encrypt-only e-mail client certs with other client uses
tacked on.

Such certificates are typically paired with a "same logical
identity" sign-only e-mail/client certificate, with the key
difference being that the encrypt-only-private key is kept around
for a lot longer in order to decrypt stored e-mails that are
(wisely) stored only in their original encrypted form.

In that /specific/ case, attempting to use the encrypt-only cert
as a TLS client cert is typically some kind of logic certificate
selection error, such as a Web client blindly using the locally
stored long-term decryption key instead of the signing key stored
on a removable, but also loosable, smart card, however there may
be company-internal reasons to do so deliberately in order for
background activities to operate when the user (and smartcard) is
"away from terminal".

Enjoy

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

Re: building openssl for windows - missing do_win64a from ms directory.

[Salz, Rich via openssl-users]

  *   The issue I have is that I don’t see ‘do_win64a’ within the ‘ms’ 
directory (I’m following build instructions here: 
http://eran.geek.co.il/wp/archives/3897
 and https://wiki.openssl.org/index.php/Compilation_and_Installation#W64 )

Those files are outdated; look at the NOTES.WIN file.

(PS that email disclaimer is obnoxious, it’d be great if you could get it 
disabled.)

Re: TLSv12 Client Certificate Selection Behavior !!

[Jakob Bohm via openssl-users]

On 11/06/2019 12:50, Hareesh D wrote:
TLSv12 client is sending RSA certificate even when it dont have 
digitalSignature bit in keyUsage extension. But RFC5246 sectiin-7.4.6 
says its MUST condition for client to send RSA certificate with 
digitalSignature bit set in keyUsage extension.


1. Though server is rejecting such certificates, not sure why client 
sends such certificates even when there is MUST condition for this 
point. Should client send empty certificate list instead of sending 
wrong one? Client has the provision of sensing empty certificate list 
when it don't have a suitable certificate according to certificate 
request.


2. And also client is not checking the certificate_types requested in 
certificate_message and also server not validating if the response is 
according to the type requested. Consider server requesting only DSA 
certificate. Client sending RSA certificate and server accepting it.


Is this behavior valid and according to RFC ?

There's an overarching OpenSSL policy that certificate checks are
done exclusively by the relying end (for client certs, that's the
server), except when certified end is trying to choose from
multiple certificates.

Thus with only one certificate available, the OpenSSL sends the
(untrusted, and in this case inappropriate) certificate, just in
case the server was somehow configured to make a special exception
for this particular case.

Enjoy

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

stunnel 5.55 released

[Michał Trojnara via openssl-users]

Dear Users,

I have released version 5.55 of stunnel.
This release addresses a number of important Windows issues, including
security vulnerabilities.

Version 5.55, 2019.06.10, urgency: HIGH
* Security bugfixes
  - Fixed a Windows local privilege escalation vulnerability
    caused insecure OpenSSL cross-compilation defaults.
    Successful exploitation requires stunnel to be deployed
    as a Windows service, and user-writable C:\ folder. This
    vulnerability was discovered and reported by Rich Mirch.
  - OpenSSL DLLs updated to version 1.1.1c.
* Bugfixes
  - Implemented a workaround for Windows hangs caused by its
    inability to the monitor the same socket descriptor from
    multiple threads.
  - Windows configuration (including cryptographic keys)
    is now completely removed at uninstall.
  - A number of testing framework fixes and improvements.

Home page: https://www.stunnel.org/
Download: https://www.stunnel.org/downloads.html

SHA-256 hashes:
90de69f41c58342549e74c82503555a6426961b29af3ed92f878192727074c62 
stunnel-5.55.tar.gz
e586b68da9e4faedf41cbcc8378402d7b188bb25b1f0f3cd1f2ce68620ef9e29 
stunnel-5.55-win64-installer.exe
7af80d424986149629aad7d75710400f58ba259042c58557adf743627b5c8e3c 
stunnel-5.55-android.zip

Best regards,
    Mike



signature.asc
Description: OpenPGP digital signature

New to the list and one question ;-)

[Patrick Regnouf via openssl-users]

Hello all, 
Hello all, 
Presently writing a server/relay dealing with an h264 stream.
one of the threads' job is to establish a handshake with the browser requesting 
the stream in order to feed the libsrtp2 with keys and salts and start 
encrypting the h264 stream towards the browser.
all is well and good when the program works on the linux PC and the handshake 
is succesful using the 0xc02f cipher. and that is linked to version 3.0.0 of 
openssl.
on the embedded version, (linked with version  1.0.2s)  firefox fails the 
handshake with ssl_no_shared_cipher whereas chrome and safari do successfully 
handshake
chrome client hello contains 12 ciphers and the server hello seems to choose 
0xc02f cipher
firefox client hello contains only 10 ciphers (including the above mentioned 
0xc02f cipher) and fails.
any suggestion as to what could causes that failure would be appreciated.
Thanks

Re: Query related to SSL_CTX_set_msg_callback_arg

[shalu dhamija via openssl-users]

 Actually while setting the callback, we can not pass the 
user-defined/application data. For example: void 
SSL_CTX_sess_set_new_cb(SSL_CTX *ctx,                             int 
(*new_session_cb)(SSL *, SSL_SESSION *));
When the callback arrives, I have SSL* and SSL_SESSION*. Earlier I was getting 
it from the 'msg_callback_arg' of SSL pointer but in the openssl1.1.1, SSL 
structure is no longer accessible.

On Sunday, 9 June, 2019, 8:27:46 pm IST, Jeremy Harris  
wrote:  
 
 On 09/06/2019 11:31, shalu dhamija wrote:
> Hi All,In openssl 1.0.2, I was using  SSL_CTX_set_msg_callback_arg() API to 
> set the application specific argument. And in the callback, I was retrieving 
> that argument from SSL pointer received in the callback e.g. 
> "ssl->msg_callback_arg"But in openssl1.1.1, the SSL structure members are no 
> more accessible. And I did not find any API to get the msg_callback_arg back. 
> Can someone please comment on this if there is any way to get the 
> msg_callback_arg back in the callbacks from ssl pointer.

When the callback is called, the arg you set is given to the callback
function, as a function argument.  It's not intended as a general-
purpose data stash.

-- 
Cheers,
  Jeremy
  

Re: Trying to use a ((constructor)) to force libcrypto.so into FIPS mode

[Andrew Tucker via openssl-users]

Assuming your OpenSSL library is already FIPS capable you need to build and
link with the FIPS container library enable the integrity check in your app.

Details are in section C.1 of the FIPS user guide at
https://www.openssl.org/docs/fips/UserGuide-2.0.pdf


On Thu, Jun 6, 2019 at 2:34 PM Larry Jordan via openssl-users <
openssl-users@openssl.org> wrote:

> Re: openssl-1.0.2r
>
> Re: openssl-fips-2.0.16
>
> OS: Linux Mint 19.1 (Ubuntu)
>
>
>
> I have added a shared library initializer function to cryptlib.c to force
> OpenSSL into FIPS mode, without requiring a “module operator” to directly
> initiate (i.e. call FIPS_mode_set(1)).
>
>
>
> void __attribute__((constructor)) ForceFIPSModeOn()
>
> {
>
>FIPS_mode_set(1);
>
>FIPS_selftest_check();
>
> }
>
>
>
> The build fails shortly after creating the executable ‘fips_premain_dso’.
>
>
>
> fips.c(140): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST
> FAILURE
>
> Aborted (core dumped)
>
>
>
> I traced the problem to a failed FIPS_check_incore_fingerprint call. The
> embedded signature appears uninitialized:
>
>
>
> Starting FIPS_selftest
> fips: 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> imem: 33 53 e6 29 f6 eb df f3 d0 23 e9 7c 39 84 91 e0 3f 32 83 b2
>  failed FIPS_check_incore_fingerprint
>
>
>
> I am at a loss to explain what is happening. Is my initializer running
> before the embedded sig is loaded? Or is there another issue.
>
>
>
> If I remove the call to FIPS_selftest_check(), the link completes, but the
> selftest still fails, when it is initiated from the initializer. A “module
> operator” can still use the libcrypto.so services, because all subsequent
> selftests pass.
>
>
>
> How can I get my module initializer to pass the selftest?
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>

SSL_check_chain() broken

[Short, Todd via openssl-users]

Hi,

It looks as though SSL_check_chain() use within the cert_cb (as recommended) 
was broken by PR 7257.

PR 7257 moves setting the shared_sigalgs to after the cert_cb takes place, but 
deep down in the call stack, SSL_check_chain() has a dependency on 
shared_sigalgs being set.

In 1.1.1, the following works, using SSL_check_chain() in the cert_cb. But it 
fails in 1.1.1a:

apps/openssl s_server -xcert apps/server.pem -xkey apps/server.pem -nocert

Is there harm in setting the shared_sigalgs before cert_cb and resetting them 
if SSL_set_SSL_CTX() is called? Basically what PR 7256 tried to do?

I opened issue 9099.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, threeif by the Internet."



smime.p7s
Description: S/MIME cryptographic signature

Re: debugging a make/dependency issue

[Salz, Rich via openssl-users]

Thanks.

I had a trailing backslash on a source list, and it gobbled up the next line 
which was an INCLUDE directive.
 

Trying to use a ((constructor)) to force libcrypto.so into FIPS mode

[Larry Jordan via openssl-users]

Re: openssl-1.0.2r
Re: openssl-fips-2.0.16
OS: Linux Mint 19.1 (Ubuntu)

I have added a shared library initializer function to cryptlib.c to force 
OpenSSL into FIPS mode, without requiring a “module operator” to directly 
initiate (i.e. call FIPS_mode_set(1)).

void __attribute__((constructor)) ForceFIPSModeOn()
{
   FIPS_mode_set(1);
   FIPS_selftest_check();
}

The build fails shortly after creating the executable ‘fips_premain_dso’.

fips.c(140): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST 
FAILURE
Aborted (core dumped)

I traced the problem to a failed FIPS_check_incore_fingerprint call. The 
embedded signature appears uninitialized:

Starting FIPS_selftest
fips: 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imem: 33 53 e6 29 f6 eb df f3 d0 23 e9 7c 39 84 91 e0 3f 32 83 b2
 failed FIPS_check_incore_fingerprint

I am at a loss to explain what is happening. Is my initializer running before 
the embedded sig is loaded? Or is there another issue.

If I remove the call to FIPS_selftest_check(), the link completes, but the 
selftest still fails, when it is initiated from the initializer. A “module 
operator” can still use the libcrypto.so services, because all subsequent 
selftests pass.

How can I get my module initializer to pass the selftest?

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

debugging a make/dependency issue

[Salz, Rich via openssl-users]

I am importing some code into openssl and getting a strange build error:

make[1]: *** No rule to make target 'crypto/bn/crypto/include.o', needed by 
'libcrypto.a'.  Stop.

Any common ideas on what to look for (e.g., missing header file, wrong INCLUDE 
settings in build.info, etc) ?

Re: Compile EC(Elliptic Curve) crypto

[Jakob Bohm via openssl-users]

On 03/06/2019 14:35, Chitrang Srivastava wrote:

Hi,

I am porting Openssl 1.1.1b for an embedded platform.
I see that EC folder generate some of function in assembly for e.g
These functions are generated based on environment like 
x86-64/ppc/armv8 etc.

Is there any C version of these function to use directly ?
Thanks,


All algorithms etc. are available as C code, the assembler optimizations
are used if they exist for a compilation target and have not been
explicitly disabled with the configure option "no-asm".

Because embedded platforms often have slow CPUs, keeping the assembler
optimizations enabled is especially advantageous on such systems.

Enjoy

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

Re: Reg missing rc4-ia64.pl in openssl 1.1.1

[Jakob Bohm via openssl-users]

On 30/05/2019 02:10, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of J. 
J. Farrell
Sent: Wednesday, May 29, 2019 15:02
On 29/05/2019 18:39, ramakrushna mishra wrote:

In Openssl 1.1.1,  the file "rc4-ia64.pl" is missing. This cause degradation of
performance on AIX. ...

The AIX port to Itanium was never released as a product, and was abandoned
altogether in 2002; I'm surprised that a degradation of performance on it
matters to anyone.

What, no love for unobtainable archaic platforms?

Note that while the OP may actually be running AIX (old beta or special
contract), IA64 had publicly released OS versions of Linux, HP-UX, Windows
(NT 5.01 to NT 6.01) and possibly others. Linux IA64 may or may not be in
some supported distributions (in addition to site OS builds), don't know
the status of HP-UX IA64, Windows NT 6.01 (== Server 2008R2) is still
publicly supported by Microsoft with options to buy private support years
on top.


Personally, I'm bemoaning the lack of a rc4-romp.pl for AIX 2 on my RT PC. And 
the shocking lack of assembly modules for the PDP-11.

In all seriousness: It's pretty cool that OpenSSL still includes assembly 
modules for what are now rather niche architectures such as MIPS and PA-RISC. 
And in case all this is too convoluted for the OP, rc4-ia64.pl doesn't apply to 
extant AIX systems, which are all some variant of POWER, not IA64.

MIPS is still a common platform in Linux-based routers, which generally
use OpenSSL as their main cryptographic library for everything from WiFi
security to OpenVPN and browser configuration.  As these are often speed
constrained chips, assembler optimizations are important.  While ARM was
making inroads in this market, RiscV or an Asian design are more likely
successor for low cost low power router hardware.

(OK, somewhere someone probably has one of the other AIX variants running - 
AIX/390 might be the last non-POWER AIX to die, if I had to bet. But probably 
not AIX IA64.)



Enjoy

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

Re: Performance Issue With OpenSSL 1.1.1c

[Jakob Bohm via openssl-users]

On 28/05/2019 23:48, Steffen Nurpmeso wrote:

Jay Foster wrote in <84571f12-68b3-f7ee-7896-c891a2e25...@roadrunner.com>:
  |On 5/28/2019 10:39 AM, Jay Foster wrote:
  |> I built OpenSSL 1.1.1c from the recent release, but have noticed what
  |> seems like a significant performance drop compared with 1.1.1b.  I
  |> notice this when starting lighttpd.  With 1.1.1b, lighttpd starts in a
  |> few seconds, but with 1.1.1c, it takes several minutes.
  |>
  |> I also noticed that with 1.1.1b, the CFLAGS automatically included
  |> '-Wall -O3', but with 1.1.1c, '-Wall -O3' is no longer included in the
  |> CFLAGS.  was this dropped?  I  added '-Wall -O3' to the CFLAGS, but
  |> this did not seem to have any affect on the performance issue
  |> (unrelated?).
  |>
  |> This is for a 32-bit ARM build.
  |>
  |> Jay
  |>
  |I think I have tracked down the change in 1.1.1c that is causing this.
  |It is the addition of the DEVRANDOM_WAIT functionality for linux in
  |e_os.h and crypto/rand/rand_unix.c.  lighttpd (libcrypto) is waiting in
  |a select() call on /dev/random.  After this eventually wakes up, it then
  |reads from /dev/urandom.  OpenSSL 1.1.1b did not do this, but instead
  |just read from /dev/urandom.  Is there more information about this
  |change (i.e., a rationale)?  I did not see anything in the CHANGES file
  |about it.

I do not know why lighttpd ends up on /dev/random for you, but in
my opinion the Linux random stuff is both sophisticated and sucks.
The latter because (it seems that many) people end up using
haveged or similar to pimp up their entropy artificially, whereas
on the other side the initial OS seeding is no longer truly
supported.  Writing some seed to /dev/urandom does not bring any
entropy to the "real" pool.

Something equivalent to your program (but not storing a bitcount field)
used to be standard in Linux boot scripts before systemd.  But it
typically used the old method of just writing the saved random bits
into /dev/{u,}random .

This makes me very surprised that they removed such a widely used
interface, can you point out when that was removed from the Linux
kernel?

Enjoy

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

OpenSSL version 1.1.1c published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


   OpenSSL version 1.1.1c released
   ===

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

   The OpenSSL project team is pleased to announce the release of
   version 1.1.1c of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

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

   OpenSSL 1.1.1c 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.1c.tar.gz
  Size: 8864262
  SHA1 checksum: 71b830a077276cbeccc994369538617a21bee808
  SHA256 checksum: 
f6fb3079ad15076154eda9413fed42877d668e7069d9b87396d0804fdb3f4c90

   The checksums were calculated using the following commands:

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

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlztM8MACgkQ1enkP335
7ow2lRAAirwJYIX4XunYXMV88tQILxAB6iCDiN04c5r5ayJqmF5Zr3QKGDG7Vj+l
q6NEmKIYpyjAxZau3orl0OC5L4Us+URFpyFpCe8BOpXjasFQYk7jycr3MI1BHYcO
dl9gVx09BZriR+q9w5xBJad34leCvuCD950+9eG/DY3+xSSWLDeagzz+dhOgTnOj
+YyMo+o/f+VucjsYddL2ehL5v744xdqu6Pu4JMceLaRdSfmKXRqwlob2w2UtCgoD
roy4+pPVLA9FYBOOYy1n2PFGopp/c67xfQX1yB35mjAB5y3FSJAWFS0gvPaHvzj1
D+zbQSxYVksOyUSrK33KnJmouaml5+CQgYRS+Umn8549A2apkIB/yRLo2K65Iuqd
KHgZGbI4cGUBEdbIxUDtvhsIr/+JlujJPvs5Eyiwm8+K/WPiZ3Hw8EXmdqTl9ITK
7URwWM4thq1sikD7RKHl4h9gEzvB6iqTd+dPbUE8jIc29HD7rPJWCw3m+gOGEoAu
L0rU4palNa1Ab6kMZ2SYsXv/rH4pl0iHBBrzVOStay/k4zPYS3eD6kytyB0vLt6g
f0u4heD4G4QiohqIFaDHjs8eSq1Paz3eA3Ylly8JKweBFTrHHssyz22ItGDCcQwz
cOb7H3o/AdXGZOSHxHtLBQqxsUcCuUID0YTyUB43bRuLnVmWs6I=
=EHRv
-END PGP SIGNATURE-

OpenSSL version 1.1.0k published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


   OpenSSL version 1.1.0k released
   ===

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

   The OpenSSL project team is pleased to announce the release of
   version 1.1.0k of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

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

   OpenSSL 1.1.0k 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.0k.tar.gz
  Size: 5287321
  SHA1 checksum: aaa2ddad0285575da7c9fa8021c26e5c8433ab15
  SHA256 checksum: 
efa4965f4f773574d6cbda1cf874dbbe455ab1c0d4f906115f867d3070b1

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.0k.tar.gz
openssl sha256 openssl-1.1.0k.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlztMKgACgkQ1enkP335
7ozB7BAArso7v+Yy6+3TiPPaH+EAYkEr2J+WQ2D17s7M9kpW8errvyX7B/yMIVSh
1ZEPfWWtmDdd9CDqfpM/P2ttipjHvrPvwh01+Re8sm+pE8me3j9N1UkqXLpRPQuW
eSAwjSYcVTgGlDlJnsDW7Yxf1vibfjA7hDHL+7MY3tdPna2rb2TICOmX1TmwR4ha
Xc6E6JAH049Rjzh9NCgcxANnembTnPqRAVmxyf6ziMmvHeDe6voYQZrtagC1CHbY
x1Y+Q3GMLtvebm7YRqoy3o29WFMPUPErcfPsun9aizmTR+UgePjQ9Tjq6bF9umTL
5Z1lt4JJsC0gUmKLTpPL0SNhAf1/TS59Usvk4pMefSq7ejteSzX1xoHY/VQ4U8pO
pO8Vsn7k8U4azuRgi3diprYhgtMDeK4udyepFTI53Bqk/H7Gm0v+R7tYYH2Zbwqm
49UuvMlP/7XHKwo0hIoV6Ul3xrNprxoXQmTG+Tm4+AoA4Qn9jELvMe96CaeLAPxG
V7NjqK7Tr4Iosso4h+Pq2oEsu3GLzXVdFYA5RORkakuX60Y8+jznKAP4WNhPS/rs
zPr8fVghb0kpctodvq2px47DVQSsUf2nYGVwu205bHpGyTKuB1ZWkYbC6cQEg3yB
SPlFyHmHWYjqk8RSmSKZSiN33x0ysG8kwr3PEJOEEe8bvF3r7cM=
=go9J
-END PGP SIGNATURE-

OpenSSL version 1.0.2s published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


   OpenSSL version 1.0.2s released
   ===

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

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2s of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

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

   OpenSSL 1.0.2s 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.0.2s.tar.gz
  Size: 5349149
  SHA1 checksum: cf43d57a21e4baf420b3628677ebf1723ed53bc1
  SHA256 checksum: 
cabd5c9492825ce5bd23f3c3aeed6a97f8142f606d893df216411f07d1abab96

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.0.2s.tar.gz
openssl sha256 openssl-1.0.2s.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlztMAcACgkQ1enkP335
7ozPdRAAnUKK6jxlMa3O2GeVDU0ZZNS3A3zyMJd2yPCB3I3b0BMxy/ZWw4A6Vtyd
l1M+GhP7/SG+kom9f6Ky2QXTW29lYQT4ImNZwU/hRI/nLKCqFw9Kzq4wqZnwlavx
pI54Loz86Ysp2PIAtWJrOPxWT7HEculhhR0yOXxWAlAkRmrbrG3JdTba3UIH0T2P
3xoncvI0ODXWE6eW3hNCtxb/npo/czcAolO/EEN60tRcZm849ODgzNqpiV5zegoF
cogfVaQFGcOncv4bYdxQIPBDBLWVEEkT+05agnFfZkv6hpIL8h2jrG4b46ULs+ZM
4iNznwLEVNVhF6Qm6RIffC3xrKIhmDZkGH8Y/ypBOTVk/vUhvot+a7Ab05fvnqeR
O5BwxUVwNsxQdZ4v4BKJM/RE1ApHuQoezOCwfPfMT2NZd3StVueQxkwSrRhtEx8k
ZnRrgtqYM8zCjqW7uVOvSIB08EZvJpIhMofIMqlfEixdTvmSvHQ8iPCQrKS0dmjA
CtWdSgFbc7NYXwj5lqfr58brKhhoap/B8MFvVaGkcqhsCp5pE/a8JO79ESI7TVQD
uxs28qhEj7RXNH61m9viOvu75ph6lfVxI/4Hat7yi/pzr4jpYYJXWM6Iz9PTf2PS
admaUdGLOUB7L51Z7/uTHuACV16SwXryJn4b0OwuTmUQ9rsdDRA=
=aI2x
-END PGP SIGNATURE-

How to use CONF_modules_load_file

[Subrata Dasgupta via openssl-users]

Hi All,In my application I am using OPENSSL_config(NULL); call to initialize 
the configuration. But it seems from openssl-1.1.1 this call is deprecated and 
we should use CONF_modules_load_file call.But it will be difficult to add new 
configuration file for openssl within my application. It will be perfect if 
some how I can use basic default configuration just like OPENSSL_config do. But 
unfortunately every time CONF_modules_load_file call is failing . I have tried 
with NULL for config file name and app name in parameters of 
CONF_modules_load_file call. Tried with different flag combination as well. But 
all in vain. Please helpThanksSubrata

Re: Compiling openssl executable as static binary

[Raveendra Padasalagi via openssl-users]

Thanks Richard, this is what I was expecting. It worked.

Configure script is not showing this option.

Configuring OpenSSL version 3.0.0-dev for target
Using os-specific seed configuration
Usage: Configure [no- ...] [enable- ...] [-Dxxx] [-lxxx]
[-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared]
[[no-]zlib|zlib-dynamic] [no-asm] [no-egd] [sctp] [386] [--prefix=DIR]
[--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--config=FILE]
os/compiler[:flags]

Regards,
Raveendra

On Thu, May 23, 2019 at 6:36 PM Richard Levitte  wrote:

> How static do you want it to be?  There is the configuration option
> '-static' that makes the binary as independent as possible, i.e. even
> links it with static libc.
>
> Cheers,
> Richard
>
> On Thu, 23 May 2019 08:26:43 +0200,
> Raveendra Padasalagi via openssl-users wrote:
> >
> >
> > Hi,
> >
> >
> >
> > Any help/pointers on compiling openssl library to generate static
> version of openssl executable
> > for ARM64 bit linux platform will help.
> >
> >
> >
> > Thanks,
> >
> > Raveendra
> >
> >
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
>

RE: Compiling openssl executable as static binary

[Raveendra Padasalagi via openssl-users]

Yes Paul.



I tried following steps:



export INSTALLDIR=/tmp/openssl_arm

export OPENSSLDIR=/tmp/openssl_arm

export PATH=$INSTALLDIR/bin:$PATH

export CROSS=aarch64-linux-gnu

export CC=${CROSS}-gcc

export LD=${CROSS}-ld

export AS=${CROSS}-as

export AR=${CROSS}-ar

export AR=${CROSS}-ar

./Configure linux-arm64 *no-shared*

make

make install



Thanks,

Raveendra

*From:* Dr Paul Dale [mailto:paul.d...@oracle.com]
*Sent:* Thursday, May 23, 2019 12:10 PM
*To:* Raveendra Padasalagi
*Cc:* openssl-users@openssl.org
*Subject:* Re: Compiling openssl executable as static binary



Link against the generated .a files rather than the .so ones?





Pauli

-- 
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
Oracle Australia







On 23 May 2019, at 4:26 pm, Raveendra Padasalagi via openssl-users <
openssl-users@openssl.org> wrote:



Hi,



Any help/pointers on compiling openssl library to generate static version
of openssl executable for ARM64 bit linux platform will help.



Thanks,

Raveendra

Compiling openssl executable as static binary

[Raveendra Padasalagi via openssl-users]

Hi,



Any help/pointers on compiling openssl library to generate static version
of openssl executable for ARM64 bit linux platform will help.



Thanks,

Raveendra

Re: why does RAND_add() take "randomness" as a "double"?

[Jakob Bohm via openssl-users]

On 22/05/2019 19:32, Dennis Clarke wrote:



Good options inspired by other cryptographic libraries include:

- Number of bits of entropy passed in call (For example, a
  perfectly balanced coin flipper could provide the 4 byte
  values "head" or "tail" with an entropy of 1 bit).


Let's drop the coin flipper. It was an off hand remark and by now we
all know there ain't no such thing as a good coin flip for rng.

    See Professor Persi Diaconis at Stanford for that :
    https://www.youtube.com/watch?v=AYnJv68T3MM

Bell's theorem and kolmogorov aside get a radiation decay source as
that is really the *only* real rng that we know of.
Or that I know of.   http://www.fourmilab.ch/hotbits/hardware.html

The coin flipper, even if theoretically problematic, is the standard
statistical example used to describe a 1-bit-at-a-time hardware RNG.

It includes a nice conceptual model to discuss hardware bias (using
Shannon's entropy formula etc.).  Actual 1-bit sources include the
classic semiconductor shot noise fed to a comparator and some primitive
implementations of radioactive RNGs.

Also, radioactive sources are an unacceptable danger in many of the
embedded and portable applications most likely to lack floating point
support.

Enjoy

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

Re: why does RAND_add() take "randomness" as a "double"?

[Jakob Bohm via openssl-users]

On 21/05/2019 16:44, Salz, Rich via openssl-users wrote:

When I overhauled the RAND mechanism, I tried to deprecate this use of floating 
point, in favor of just a number from 0 to 100 but was voted down.

It *is* stupid.  Luckily, on a modern system with system-provided randomness to 
seed the RNG, you never need this call.




Perhaps it would have been more acceptable to use a binary base,
instead of a decimal percentage, as there is nothing inherently
decimal about this value.

Good options inspired by other cryptographic libraries include:

- Number of bits of entropy passed in call (For example, a
 perfectly balanced coin flipper could provide the 4 byte
 values "head" or "tail" with an entropy of 1 bit).

- 256th of bits ditto (for example a coin flipper with a known
 slight imbalance could report 252/256th of a bit for each flip
 included in the buffer).

- 32th of bits ditto (makes the "100%" case equal to
 (bytecount << 8)).

In each of those 3 cases, the internal measure of "entropy
left" would be in that same unit, and a compatibility mapping
for the old API would do the conversion of the double as a
pure inline macro that doesn't trigger "float used" compiler
magics in programs that don't use it.

Clarifying notes:

- The current limit of considering only 32 bytes of entropy
 is an artifact of the current set of RNG algorithms, and
 should not be exposed in the API design.  For example
 future addition of post-quantum algorithms may necessitate
 having an RNG with an internal state entropy larger than
 256 bits.

- Future RNG implementations may include logic to safely
 accumulate obtained entropy into "batches" before updating
 the RNG state, as this may have cryptographic benefits.

- The use of a dummy double to force the alignment of
 structures and unions to the "highest known" value can
 be trivially replaced by another type where it is not
 already treated as "not actually floating point
 operations" by the compiler.  For example by passing
 "-Ddouble=long long" as a compiler option.

- The use of floating point registers in CPU-specific
 vector unit optimizations can be readily avoided by
 a no-asm compile.

- Floating point calculations in test programs such as
 "openssl speed" is not relevant to actual library use.

- On Linux x86, test programs that avoid all floating
 point can be checked via the PF_USED_MATH flag or its
 upcoming Linux 5.x replacement.  This may be useful
 in the test suite.


Enjoy

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

Re: why does RAND_add() take "randomness" as a "double"?

[Salz, Rich via openssl-users]

>Then just set it to 1.0 and be done with it.

>That hardly helps on systems that don't have floating point at all. 

No it doesn't.  Such systems aren't supported by OpenSSL.  There are many 
places were floating point is used/supported.
Removing the second arg to RAND_add is the least of the problems (look at 
various asm files)

Re: why does RAND_add() take "randomness" as a "double"?

[Salz, Rich via openssl-users]

>If it's a sarcasm, I'm missing the point.
  
I was't being sarcastic, I was trying to show that the team, recently, still 
liked the use of floating point.

>There are use cases when one wants to mix/add extra randomness from, e.g., 
> an external source (that, for whatever reasons, is trusted more than what's 
> provided by the system).
 
Then just set it to 1.0 and be done with it.

Re: why does RAND_add() take "randomness" as a "double"?

[Salz, Rich via openssl-users]

When I overhauled the RAND mechanism, I tried to deprecate this use of floating 
point, in favor of just a number from 0 to 100 but was voted down.

It *is* stupid.  Luckily, on a modern system with system-provided randomness to 
seed the RNG, you never need this call.

OpenSSL 1.1.1b installation

[DeCaro, James John (Jim) CIV DISA SD (US) via openssl-users]

Hello,

I am working on a Solaris 11.4 x86 64bit virtual server.  There are no specific 
applications loaded on it yet.  I am preparing it to be a BIND server 
eventually.

To that end, I downloaded and installed OpenSSL 1.1.1b so I have the latest and 
greatest to work with.

The installation seemed to go well.  Installed a gcc compiler, ran ./configure, 
make, make test and make install accepting the defaults.  No errors.  When I 
run the #openssl version -a it shows the previous version of openssl.

I have tried researching the issue, and attempting to set additional PATH 
variables in the root .profile to include /usr/local.  I think I may need to 
set symbolic links, but I am not sure.

Any assistance would be appreciated.


V/R
Jim DeCaro
DISA
Systems Administrator
SE62/Server Operations
☎ 301-225-8180 
☎ 301-375-8180 
james.j.decaro3@mail.mil
james.j.decaro3@mail.smil.mil

Query related to session resumption in TLS1.3

[shalu dhamija via openssl-users]

Hi All,


I am in process of using TLS1.3 using openssl 1.1.1b version in my client 
application. In order to use session resumption, I have implemented an external 
cache when acting as the client. The key to the cache is combination of host 
and port and the value  associated is SSL_SESSION*.   Before calling 
ssl_connect, I am checking if the entry corresponding to the key exists in the 
map. If it exists, I am calling SSL_set_session. After ssl_connect, I am 
checking if the session is reused or not using SSL_Session_Reused. If its not 
reused, I am inserting the new session obtained as a result of call to 
SSL_get1_session() in the map.
Pseudo code is as follows:
std::map sessionCache;/* Generate an SSL client 
context. */SSL_CTX* ctx = SSL_CTX_new(TLS_method());SSL* ssl = SSL_new(ctx); 
//Check if we have a stored session it = sessionCache.find (key);if (it != 
sessionCache.end()) { SSL_set_session (ssl, it->second)}
SSL_connect(ssl);int reUsed = SSL_session_reused(ssl);if (!reUsed) { session = 
SSL_get1_session(ssl); sessionCache.insert (key, session);}
The above flow works well using TLS1.2. I can see that SSL_session_reused 
returns true in the second connection. 
But the same flow does not work for TLS1.3. In TLSv1.3, sessions are 
established after the main handshake has completed. So, I have implemented the 
callback  SSL_CTX_sess_set_new_cb.  And in the callback, I am storing the 
session into the cache. In subsequent connections, the session is present in 
the map, SSL_set_session API returns true. But SSL_session_reused is always 
returning false.
I have the following queries:1. Is the above mentioned approach applicable for 
TLS 1.3? 2. There is a mention that PreShared keys are used for session 
resumption in TLS1.3.  Can someone please clarify, how should I make my client 
send psk using openssl for subsequent connection?

Re: Build the FIPS Object Module issue on Ubuntu 18.04

[Jakob Bohm via openssl-users]

On 16/05/2019 02:11, Paul Dale wrote:

Just noting that any module built in this manner is *not* FIPS compliant.

The distribution must be unmodified and build exactly as per the documentation. 
 Any change to the files or the build process renders the result invalid from a 
FIPS perspective.


Only deviations from the official process in creating the
fipscanister invalidates the FIPS validation.

The FIPS-capable OpenSSL is "outside the boundary" of the
FIPS module and can be changed at will.  This is why a new
FIPS validation is not needed every time OpenSSL releases
a bugfix to OpenSSL 1.0.x .  1.1.x will not have FIPS
support, and 4.y.x may lack this agility.

Enjoy

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

stunnel 5.54 released

[Michal Trojnara via openssl-users]

Dear Users,

I have released version 5.54 of stunnel.

Version 5.54, 2019.05.15, urgency: LOW
* New features
  - New "ticketKeySecret" and "ticketMacSecret" options
    to control confidentiality and integrity protection
    of the issued session tickets.  These options allow
    for session resumption on other nodes in a cluster.
  - Added logging the list of active connections on
    SIGUSR2 or with Windows GUI.
  - Logging of the assigned bind address instead of the
    requested bind address.
* Bugfixes
  - Service threads are terminated before OpenSSL cleanup
    to prevent occasional stunnel crashes at shutdown.

Home page: https://www.stunnel.org/
Download: https://www.stunnel.org/downloads.html

SHA-256 hashes:
5e8588a6c274b46b1d63e1b50f0725f4908dec736f6588eb48d1eb3d20c87902 
stunnel-5.54.tar.gz
ed8424731f7d6e0c9b11f4c7b597a072e558dae7979102d0b213759678079481 
stunnel-5.54-win64-installer.exe
7659f605065e5155577a99abe1129dbc89523796196c8bf50d3fa9265ec34d93 
stunnel-5.54-android.zip

Best regards,
    Mike




signature.asc
Description: OpenPGP digital signature

Re: Crashes when generating certificate

[Jakob Bohm via openssl-users]

On 14/05/2019 18:39, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Karl Denninger
Sent: Tuesday, May 14, 2019 09:22
On 5/14/2019 09:48, Michael Wojcik wrote:

I can't think of what remnant of the old certificate would be there,
except the certificate itself, in whatever the configuration file
specifies for the new_certs_dir. And I've never seen that cause this problem.

There's a directory (by default "newcerts" but can be changed in the config
file) that has a copy of the certs that OpenSSL generates.

Yeah, that's the new_certs_dir that I referred to. (That's the name of the 
config
file setting.)


  If there's a collision in there (which could happen if the serial number is
reused) "bad things" could happen.

Right, the filename is taken from the serial number. So if the ca app does 
something
like an open(..., O_CREAT | O_EXCL), and that fails, it might quit.


  I've not looked at the code to see if that would cause a bomb-out but the
risk with playing in the database file, although it's just a flat file,
and/or the serial number index is that you can wind up with conflicts.

Agreed.

Let's see... In 1.1.1b, the ca app does a BIO_new_file for the new
certificate file, and if that returns null, it does a perror followed by a goto 
end.

I don't know what version the OP is running, though, and that perror may be 
missing in older OpenSSL releases. (Why do people post questions without 
identifying their OpenSSL version, platform, and so on?)

Interestingly, right before that the ca app does a bio_open_default on outfile, 
which is the argument of the -out option (if any) or null for the default 
(stdout, I think); and if *that* fails it does a goto end without a perror. So 
if OP's command line has a -out and that file can't be open for output, ca will 
exit silently.


The "ca" function in openssl lacks the sort of robustness and "don't do that"
sort of protections that one would expect in a "production" setting.  That's not
say it can't be used that way but quite a bit of care is required to do so
successfully, and toying around in the database structure by hand is rather
removed from that degree of care.

Oh, definitely. I wouldn't recommend using openssl ca for any sort of 
production use unless you're confident you understand how openssl ca works, how 
PKIX works, how production CAs are supposed to work, and any details particular 
to your use, such as CA/BF requirements if you want to generate certificates 
for HTTPS servers. And then you need a lot of infrastructure around the ca app, 
including at least partial automation for all the CA operations, a mechanism 
for key hygiene, backups, auditing, and so on.

Unfortunately, the CA function isn't really suitable for a free turnkey 
implementation (too many variables, too many infrastructure requirements), but 
customers who don't already have some kind of organizational CA need some way 
to get started with TLS. For many years we've shipped a demonstration CA based 
on openssl ca plus some scripts with some of our products, and some customers 
insist on using it in production, despite our warnings against it. I'm not 
happy about it, but we haven't found a good alternative.

Despite its obvious shortcomings, I have yet to find another ca program
suitable for offline use on a small command-line only machine. Everything
I have found has been bloated GUI stuff with builtin web servers and other
unwanted garbage.

It would be nice if a good command-line offline CA product existed, but
until then, disciplined use of the OpenSSL ca "sample" command seems to be
the best there is.

Enjoy

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

Re: OpenSSL 1.1.1b tests fail on Solaris - solution and possible fix

[Jakob Bohm via openssl-users]

Alternative suggestion (from my understanding of the documentation quoted
below):

Issue #pragma weak for a symbol only in the files that define that symbol,
not in the ones that merely reference it.

The hoped effect would be:

1. Object files that merely reference a symbol will contain regular UNDEF
  entries
2. Object files that do define such a symbol will contain a WEAK defined
  entry
3. When seeing the UNDEF entries, the linker will look for an actual
  definition
4. If finding multiple WEAK defined entries, the linker will not complain,
  just use the first found.

I suspect the specified linker semantics of not trying to satisfy "WEAK
UNDEF" entries would be suitable for optional link-time selected callbacks
or data where a referencing library do runtime tests to see if the library-
using program has provided a definition or not.  For example, it could be
used for a symbol holding a list of global C++ constructors/destructors
with libc code invoking that list if present without requiring dummy lists
in programs without.

The .so case mentioned probably works "by chance" because libssl.so
references non-weak libcrypto.so symbols, forcing the definition to be
included in the runtime process anyway.

On 14/05/2019 11:29, John Unsworth wrote:

Because of the #pragma weak directive the functions are defined multiple times 
in both libcrypto.a and libssl.a:

libcrypto.a

Many UNDEF:
ct_log.o
[47]|   0|   0|FUNC |WEAK |0|UNDEF  
|OPENSSL_sk_new_null
... and more

One definition from stack.c as you'd expect:
stack.o
[33]|1232|  20|FUNC |WEAK |2|2  
|OPENSSL_sk_new_null

libssl.a has multiple instances also, all UNDEF:
d1_srtp.o
[43]|   0|   0|FUNC |WEAK |0|UNDEF  
|OPENSSL_sk_new_null
s3_lib.o
[107]   |   0|   0|FUNC |WEAK |0|UNDEF  
|OPENSSL_sk_new_null
and so on.

 From the linker docs:
B.2.17.1 #pragma weak name
In the form #pragma weak name, the directive makes name a weak symbol. The 
linker will not complain if it does not find a symbol definition for name. It 
also does not complain about multiple weak definitions of the symbol. The 
linker simply takes the first one it encounters.

So when linking with libcrypto.a and libssl.a the first definition is taken 
which is UNDEF in both cases leading to the error.
This can be fixed in libcrypto.a by making stack.o, lh_stats.o and lhash.o the 
first files included. It could also be fixed by not defining those pragmas when 
compiling stack.c, lh_stats.c and lhash.c because they will then be GLOB 
instead of WEAK and will override all the WEAK definitions.

However there is no suitable fix for libssl.a because those files are not part 
of that library.

Doing that means that executables that link libcrypto.a before libssl.s are 
built correctly. However if the link is libssl.a followed by libcrypto.a the 
UNDEF symbols from libssl.a are still used.

In the shared libraries I see:

libcrypto.so only instance:
[3537]  | 2409672|  20|FUNC |LOCL |2|10 
|OPENSSL_sk_new_null

Shared libssl.so also one instance:
[2091]  |   0|   0|FUNC |WEAK |0|UNDEF  
|OPENSSL_sk_new_null

and it seems that the linker will resolve those correctly.

So it seems to me that the only clean solution is to not define those pragmas 
when compiling stack.c, lh_stats.c and lhash.c by including a suitable define 
in the makefiles when building the libraries that is used in safestack.h and 
lhash.h to omit them.

I see there is also
# elif defined(__SUNPRO_C)
#pragma weak getisax
in crypto\sparcv9cap.c
so maybe that needs consideration too.

Regards,
John.

-Original Message-
From: openssl-users  On Behalf Of John 
Unsworth
Sent: 10 May 2019 16:23
To: openssl-users@openssl.org
Subject: RE: OpenSSL 1.1.1b tests fail on Solaris - solution

CAUTION: This email originated from outside of Synchronoss.


This seems to be caused by the ongoing saga documented in issues 6912 and 8102. 
These functions were declared as weak in 1.1.1b.

safestack.h
#  pragma weak OPENSSL_sk_num
#  pragma weak OPENSSL_sk_value
#  pragma weak OPENSSL_sk_new
#  pragma weak OPENSSL_sk_new_null
...

lhash.h
#  pragma weak OPENSSL_LH_new
#  pragma weak OPENSSL_LH_free
#  pragma weak OPENSSL_LH_insert
#  pragma weak OPENSSL_LH_delete
...

Removing these lines allows all the tests to work. I am building static 
libraries (no-shared) which is presumably why it works for some people out of 
the box if they are using shared libraries.

Please advise as to the way forward. I note that one other user (see 8102) has 
reported this too:

rammishr commented on Mar 26
Hi,
Sorry if this should have been posted separately.

When i build openssl1.1.1b on solaris , it is successful. But while verifying the version 
" openssl version" it fails with below error.
ld.so

Building openssh7.9p1 and above against openssl1.1.1b

[Samiya Khanum via openssl-users]

Hi,

After upgrading openssl to 1.1.1b, I am getting compilation errors in the
openssh code.

Does Openssh 7.9p1 and above versions support building against the openssl
1.1.1b version?
In Openssh release notes, below note is mentioned:

All: support building against the openssl-1.1 API (releases 1.1.0g
   and later). The openssl-1.0 API will remain supported at least
   until OpenSSL terminates security patch support for that API version.

Does this mean it is supported?

Thanks & Regards,
Samiya khanum

Re: opensslconf.h file not generated

[Samiya Khanum via openssl-users]

Hi Richard,

When I executed "make" in openssl directory, opensslconf.h file is
generated. When I do "make" in our projects build directory, opensslconf.h
is not generated.
 is this file generated by Configure command or make command?

On Mon 13 May, 2019, 10:56 PM Richard Levitte,  wrote:

> Well, you do need to actually build it, i.e. run "make"
>
> What I want to do is exactly what you did that got you that error.
> What command did you run after configuring?
>
> Cheers,
> Richard
>
> On Mon, 13 May 2019 07:19:31 -0700,
> Samiya Khanum wrote:
> >
> >
> > Hi Richard,
> >
> > I have extracted tar file and executed Configure command. Do we need to
> set anything before
> > Configure?
> >
> > On Mon 13 May, 2019, 7:33 PM Richard Levitte, 
> wrote:
> >
> > What else did you do other than configuring?
> >
> > Cheers
> > Richard
> >
> > Samiya Khanum via openssl-users  skrev:
> (13 maj 2019 05:19:18
> > GMT-07:00)
> > >Hi,
> > >
> > >Earlier our application used openSSL version 1.0.2n. We want to
> upgrade
> > >to
> > >1.1.1b.
> > >When I compile openssl, I see "opensslconf.h" not found error.
> > >
> > >../../../../vendor/openssl/include/openssl/e_os2.h:13:34: fatal
> error:
> > >openssl/opensslconf.h: No such file or directory
> > >
> > >With below configure options, opensslconf.h file is not generated. I
> > >tried
> > >giving --prefix, --openssldir, disable-deprecated options as well.
> > >
> > >./Configure linux-generic32
> > >
> > >./Configure \
> > >no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc5 \
> > >-DOPENSSL_SYSNAME_LINUX -DOPENSSL_USE_IPV6
> > >-DOPENSSL_IMPLEMENTS_strncasecmp \
> > >-ffunction-sections -fdata-sections \
> > >    shared no-hw no-asm \
> > >-m32 linux-generic32
> > >
> > >Am I missing any option in Configure. Can someone help me on this.
> > >
> > >Thanks & Regards,
> > >Samiya khanum
> >
> > --
> > Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
> >
> >
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
>

Re: opensslconf.h file not generated

[Samiya Khanum via openssl-users]

Hi Richard,

I have extracted tar file and executed Configure command. Do we need to set
anything before Configure?

On Mon 13 May, 2019, 7:33 PM Richard Levitte,  wrote:

> What else did you do other than configuring?
>
> Cheers
> Richard
>
> Samiya Khanum via openssl-users  skrev: (13
> maj 2019 05:19:18 GMT-07:00)
> >Hi,
> >
> >Earlier our application used openSSL version 1.0.2n. We want to upgrade
> >to
> >1.1.1b.
> >When I compile openssl, I see "opensslconf.h" not found error.
> >
> >../../../../vendor/openssl/include/openssl/e_os2.h:13:34: fatal error:
> >openssl/opensslconf.h: No such file or directory
> >
> >With below configure options, opensslconf.h file is not generated. I
> >tried
> >giving --prefix, --openssldir, disable-deprecated options as well.
> >
> >./Configure linux-generic32
> >
> >./Configure \
> >no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc5 \
> >-DOPENSSL_SYSNAME_LINUX -DOPENSSL_USE_IPV6
> >-DOPENSSL_IMPLEMENTS_strncasecmp \
> >-ffunction-sections -fdata-sections \
> >shared no-hw no-asm \
> >-m32 linux-generic32
> >
> >Am I missing any option in Configure. Can someone help me on this.
> >
> >Thanks & Regards,
> >Samiya khanum
>
> --
> Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.
>

opensslconf.h file not generated

[Samiya Khanum via openssl-users]

Hi,

Earlier our application used openSSL version 1.0.2n. We want to upgrade to
1.1.1b.
When I compile openssl, I see "opensslconf.h" not found error.

../../../../vendor/openssl/include/openssl/e_os2.h:13:34: fatal error:
openssl/opensslconf.h: No such file or directory

With below configure options, opensslconf.h file is not generated. I tried
giving --prefix, --openssldir, disable-deprecated options as well.

./Configure linux-generic32

./Configure \
no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc5 \
-DOPENSSL_SYSNAME_LINUX -DOPENSSL_USE_IPV6
-DOPENSSL_IMPLEMENTS_strncasecmp \
-ffunction-sections -fdata-sections \
shared no-hw no-asm \
-m32 linux-generic32

Am I missing any option in Configure. Can someone help me on this.

Thanks & Regards,
Samiya khanum

Re: openssl failed to connect to MS Exchange Server (Office365) on RHEL 7.x

[Jakob Bohm via openssl-users]

Your transcript below seems to show a successful connection to Microsoft's
cloud mail, then Microsoft rejecting the password and closing the 
connection.


You are not connecting to your own Exchange server, but to a central 
Microsoft
service that also handles their consumer mail accounts (hotmail.com, 
live.com,
outlook.com etc.).  This service load balances connections between many 
servers

which cab give different results for each try.

On 10/05/2019 17:01, Chandu Gangireddy wrote:

Dear OpenSSL Users,

At my corporate environment, I'm experience a challenge to use openssl 
s_client utility. I really appreciate if someone can help me narrow 
down the issue.


Here the details -

Platform: RHEL 7.x
*Openssl version:*
OpenSSL 1.0.2k-fips  26 Jan 2017
built on: reproducible build, date unspecified
platform: linux-x86_64
options:  bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) 
idea(int) blowfish(idx)
compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB 
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT 
-m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
-grecord-gcc-switches   -m64 -mtune=generic -Wa,--noexecstack -DPURIFY 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
-DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM

OPENSSLDIR: "/etc/pki/tls"
engines:  rdrand dynamic

Command tried to tes the connectivity between my Linux client server 
to remote office 365 exchange server using POP3 port -


$ openssl s_client -crlf -connect outlook.office365.com:995 
<http://outlook.office365.com:995>

...
...
subject=/C=US/ST=Washington/L=Redmond/O=Microsoft 
Corporation/CN=outlook.com <http://outlook.com>

issuer=/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3952 bytes and written 415 bytes
---
New, TLSv1/SSLv3, 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
    Session-ID: 
072FFFDC6177DE9CAB2B59EA06E486A25AD8A2882A9B82F16678BAD74E79

    Session-ID-ctx:
    Master-Key: 
DD7B59F38867FEAB9656B519FBCD743158E528C63FF9A96CE758120424159F26967F9F6FE57A9B5E7CAD806798322278

    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1557500061
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
+OK The Microsoft Exchange POP3 service is ready. 
[QgBOADYAUABSADEANABDAEEAMAAwADQAMgAuAG4AYQBtAHAAcgBkADEANAAuAHAAcgBvAGQALgBvAHUAdABsAG8AbwBrAC4AYwBvAG0A]

*USER netco...@cox.com <mailto:netco...@cox.com>*
*+OK*
*PASS *
*-ERR Logon failure: unknown user name or bad password.*
*quit*
*+OK Microsoft Exchange Server POP3 server signing off.*
*read:errno=0*

Operating System:
Red Hat Enterprise Linux Server release 7.2 (Maipo)

When I did the same from a different server, it worked as expected. 
Following are the two difference which I noticed between a working 
server and non-working server.

*
*
*Working server details:*
1. Red Hat Enterprise Linux Server release 6.9 (Santiago)
2. openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Mon Jan 30 07:47:24 EST 2017
platform: linux-x86_64
options:  bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) 
idea(int) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN 
-DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic 
-Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
-DWHIRLPOOL_ASM -DGHASH_ASM

OPENSSLDIR: "/etc/pki/tls"
engines:  dynamic

Please let me know if you need any further details from my end.

Thanks, in advance.
Chandu



--
Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 


This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: Building OpenSSL with Emscripten

[Jakob Bohm via openssl-users]

By the way, has anyone worked on a feature or patch to use browser
provided crypto functions (WebCrypto etc.) when compiled to
pseudo-javascript via EmScripten or WebAssembly?

On 10/05/2019 07:43, Dr Paul Dale wrote:

Configure with the _no-asm_ option.

It will be a **lot** slower.


On 10 May 2019, at 3:33 pm, Sunghyun Park <mailto:sun...@umich.edu>> wrote:


Nice to meet you all :)

I faced a problem while building assembly code in OpenSSL (e.g., 
crypto/x86_64cpuid.s) with Emscripten.
Since Emscripten does not support compilation for assembly code (As 
far as I know), I'm wondering if there is any version of OpenSSL that 
does not require compiling assembly code.
Or, if there is anyone who experienced the similar problem, please 
share your experience.





Enjoy

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

Re: Reg slowness seen in openssl 1.1.1

[Salz, Rich via openssl-users]

>  Could you please look into the program and let me know if anything  I am 
> doing wrong ?
> Or else What could be the issue ?

Sorry, no not me.  Maybe someone else on the list has ideas.

Re: Reg slowness seen in openssl 1.1.1

[Salz, Rich via openssl-users]

So now you know where to start looking, I guess.  You might also change your 
test program so that it calls the functions multiple times, to “smooth out” the 
overhead.

Re: Reg slowness seen in openssl 1.1.1

[Salz, Rich via openssl-users]

I would start with doing profiling on old and new versions to see where the 
slowdown is.

Re: configuring callbacks (or not) and SNI vs not... no shared cipher from server end

[Benjamin Kaduk via openssl-users]

On Wed, May 08, 2019 at 04:40:07PM -0400, Michael Richardson wrote:
> 
> Viktor Dukhovni  wrote:
> >> Diversionary issue:
> >> 
> https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html
> >> and:
> >> 
> https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html
> >>
> >> are pretty vague.  I think that SSL_set_tlsext_host_name() is probably
> >> intended to be used on the client to set the SNI, but I'm not sure.
> 
> > Yes, e.g. in the Postfix TLS client:
> 
> > 
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1035-L1045
> 
> So, okay.
> Either this URL can go into the man page, or some short code extract could go 
> in.

Probably better to have a code snippet (filing a github issue or sending
a pull request would probably be good).

> >> The legacy cb function returns int, but it's values are not
> >> documented.
> 
> > On the server side I'm using SSL_CTX_set_tlsext_servername_callback():
> 
> > 
> https://github.com/vdukhovni/postfix/blob/2399e9e179ee025d03155fa3637cccab0a23ddce/postfix/src/tls/tls_misc.c#L1040-L1043
> > 
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L668
> 
> >> I guess the point is that CB can set the server certificate to
> >> something appropriate, or I think, it could just decide to ignore the
> >> SNI value completely and force the certificate regardless.
> 
> > Yes.
> 
> I can see that the CB provides comprehensive functionality, but I worry about
> applications trying to parse ClientHello extensions themselves and getting it 
> wrong.

It turns out that the server_name TLS extension is something of an
unfortunate exception in terms of the unneeded complexity in its
encoding.  When I wrote the client_hello_cb functionality (at the time,
know as the early_cb), I thought about whether I wanted to add a
dedicated API just for the SNI value, due to the level of complexity
involved.  I ended up not doing so in the initial submission, both
because I figured it could safely be added later as an incremental
change, and because I was worried (IIRC) about being tempted to expose
some of the PACKET_* APIs in the process, which is not really the right
architectural choice for OpenSSL.

There is, however, an existing implementation for extracting the SNI
value in the test code at
https://github.com/openssl/openssl/blob/master/test/handshake_helper.c#L150-L187
that has been successfully extracted and used in a couple places I know
of.

> >> What is the SNI functionality otherwise on the server?
> 
> > You can interpose a secondary "virtual-host-specific" SSL_CTX for for
> > the rest of the handshake.  This carries the server certificate, but
> > also the trust store settings for validating client certificates, the
> > settings to request (or not) client certificates, the verification
> > callbacks, ...  It is a rather heavyweight object, best cached and
> > re-used for multiple connections.
> 
> So, it's okay to change the SSL_CTX for an SSL* after creation.
> That is rather surprising to me, but I guess it's okay.
> I suppose I feel that there ought to be reference counts, but this is C, not 
> Rust.

There *are* reference counts.

> > In Postfix, it is configured with the same settings as the initial
> > SSL_CTX, *but* no server certificates.  During the SNI callback I
> > interpose the certificate-less context, and then set the certificate
> > chain on the connection handle (SSL *) instead.
> 
> okay, I'll use Postfix as my reference :-)

For "how to use and switch SSL_CTXs" I'm sure it's admirable, but my
understanding is that it's still using the legacy server_name callback
(as opposed to the new client_hello_cb), and the new callback has a lot
of advantages for architectural cleanliness and avoiding some surprising
behavior with respect to the ordering of certain processing in the
server.  So for a greenfield application I'd still suggest using the
client_hello_cb (not that I'm entirely unbiased...).

-Ben

> >> Is there any support for picking a certificate based upon the SNI
> >> name?
> 
> > The application does the "picking"...  The application sets one or more
> > certificate chains (one per supported public key algorithm) that best
> > match the SNI name, and then OpenSSL chooses one of these based on the
> > client's advertised supported signature algorithms, ...
> 
> What I was observing (wrongly) was that maybe the server was doing something
&g

Re: EVP_aes_128_cbc_hmac_sha256() not working on arm64 architecture

[Jakob Bohm via openssl-users]

For future library versions (4.x or whatever), it would be useful to
make these combo-ciphers be better documented and available via
library-level calls to separate block and mac operations where
optimized intertwined implementations are not provided.

Obviously, the set of such combo loops should be enhanced with the
CBC-then-HMAC and other now popular combinations.

But just because SSL notoriously did the surrounding logic (padding,
IV management etc.) completely wrong every time (CBC then MAC is
also a weak choice!) doesn't mean the composition of doing HMAC
on CBC input is inherently bad in skilled hands.

Blindly using only whatever is now in fashion isn't necessarily
safe either, they just haven't found and published the attacks
yet.

On 07/05/2019 21:47, Mirko J. Ploch wrote:
Thank you for your response. You answered my question. It is not 
available on my target platform architecture (arm64).


I do have a specific need for that cipher, and it does not have 
anything to do with TLS. An app that I am working on requires it for 
JSON Web Encryption (JWE) as the required encryption algorithm.


https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-31#appendix-B

On Tue, May 7, 2019 at 11:45 AM Matt Caswell <mailto:m...@openssl.org>> wrote:




On 06/05/2019 16:41, Mirko J. Ploch wrote:
> Hello,
>
> I'm trying to use EVP_aes_128_cbc_hmac_sha256() for encryption
on an iOS device
> with arm64 architecture. I was able to get it working with the
x86_64
> architecture when running the iOS device simulator on an iMac.
Is this just not
> capable of working on an arm64 platform?
>
> Looking at the code for EVP_aes_128_cbc_hmac_sha256, it does not
look like it.
> I'm hoping that there is a way to get it working.
    >

https://github.com/openssl/openssl/blob/OpenSSL_1_1_1b/crypto/evp/e_aes_cbc_hmac_sha256.c

This cipher is a special purpose cipher not intended for general
use. It is
specifically targeted at usage in TLS. Unless you're writing a TLS
stack you
probably don't want to use this. It is only available on some
platforms and does
runtime detection to check whether the platform is suitable or
not. Most
importantly the platform must have AES-NI support.

It's usefulness even in a TLS stack is somewhat limited these days
since it is
not relevant for TLSv1.3 and does not get used if encrypt-then-mac
is negotiated
(which recent versions of OpenSSL will try to negotiate by default).





Enjoy

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

Re: Custom secure heap implementation

[Salz, Rich via openssl-users]

The intent is that you replace the upper layer, CRYPTO_secure_x

What does your implementation do differently, and which platforms does it work 
on?

Re: Reg: Building Openssl 1.1.1b for Borland

[Jakob Bohm via openssl-users]

On 26/04/2019 08:19, Richard Levitte wrote:

On Fri, 26 Apr 2019 07:05:01 +0200,
Ande Vishnuvardhan Reddy wrote:

We would like to build Openssl 1.1.1b with Borland compiler (bcc32 - 
Embarcadero C++ 7.40). Seems
support for Borland is removed from 1.1.x .

It was dropped, that's true.  The main reason was lack of docs (or not
being able to find the docs)


Could you please help in building Openssl 1.1.1b with Borland?
Please suggest what are the conf files to be added to generate makefile.

It's not just about the conf file, you most probably need a separate
Makefile template too.  For starters, I assume Borland comes with some
kind of make utility...  or do Borland users use something else?
What's its default Makefile name?

At least older versions (5.x) included a MAKE.EXE which was more
predictable than MS's NMAKE.EXE.  The compilers could be invoked
from any other make tool (nmake, GNU make etc.), but Borland's
MAKE.EXE had an option to extract source file and header
dependencies directly from the object files being checked for
staleness, thus allowing simpler rules that don't mention all the
used headers.  However I guess the OpenSSL build system already
contains the needed dependencies anyway.

Also, Borland C/C++ used to stick to the old OMF object file format,
not the COFF format used by Microsoft tools.

Enjoy

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