libressl / openbsd Goto Github PK

Hi,

list-message-digest-commands seems does not list all digest commands.

# openssl list-message-digest-commands
md4
md5
rmd160
sha
sha1

by openssl dgst -help,

-gost-mac       to use the gost-mac message digest algorithm
-streebog512    to use the streebog512 message digest algorithm
-streebog256    to use the streebog256 message digest algorithm
-md_gost94      to use the md_gost94 message digest algorithm
-md4            to use the md4 message digest algorithm
-md5            to use the md5 message digest algorithm
-mdc2           to use the mdc2 message digest algorithm
-ripemd160      to use the ripemd160 message digest algorithm
-sha            to use the sha message digest algorithm
-sha1           to use the sha1 message digest algorithm
-sha224         to use the sha224 message digest algorithm
-sha256         to use the sha256 message digest algorithm
-sha384         to use the sha384 message digest algorithm
-sha512         to use the sha512 message digest algorithm
-whirlpool      to use the whirlpool message digest algorithm

from man page OPENSSL(1),

     openssl gost-mac | streebog256 | streebog512 | md_gost94 | md4 | md5 |
     mdc2 | ripemd160 | sha | sha1 | sha224 | sha256 | sha384 | sha512 |
     whirlpool [-c] [-d] [file ...]

Thanks.

The function bn_wexpand() can fail. Most of the invocations in bn_g2fm.c are guarded, but three of them aren't, causing a null pointer dereference when bn_wexpand() fails:

https://github.com/libressl-portable/openbsd/blob/80e93e1153038e48e7bdb4236e9174f91b6375dd/src/lib/libssl/src/crypto/bn/bn_gf2m.c#L705

Courtesy of GitHub search, this other group of calls in ec2_mult.c is also suspicious:

https://github.com/libressl-portable/openbsd/blob/37759485f52993eb812898ccd70fc42cd92cdad5/src/lib/libssl/src/crypto/ec/ec2_mult.c#L292

Hello!
I'm In the midst of writing a Haskell binding to libtls / libressl (in their portable build incarnation), and it seems that I can't expose alpn information unless I either violate / use the private struct rep at the libtls layer or do a more direct wrapping of the underlying libressl APIs. I'm totally fine with doing the latter. But seems like an oversight from the perspective of making it easy for a libtls user to write a simple https-v2 client or server library leveraging the libtls Api.

This may or may not have been discussed previously or already be a known issue, but I figure erring on the side of over communication :)

Cheers!

In de5a7bf#diff-c72c45bb1891a4148a352b678fe463d4 X509_cmp_time has changed in that the string must be representable by time_t.

This causes it to fail for large dates on 32bit platforms (tested on Ubuntu) where time_t is 32bit causing certificates that have a really far future expiration (e.g. 100 years from now) to no longer verify successfully.

Such certificates verify with OpenSSL/BoringSSL.

The original OpenSSL API used unsigned char* a lot for strings, and currently libressl does as well. While this is mostly harmless (warning-level at most) in C, this is kinda PITA for using libressl from C++ code.

Is there any particular reason for using it? String literals in both C and C++ are of plain const char* type. char* is used by standard C library I/O routines, ncurses, readline, glib (via gchar)… which pretty much means that the program is always required to convert char* to unsigned char* for libressl.

For example, the following is invalid in C++:

X509_NAME_add_entry_by_txt(name, "O", MBSTRING_ASC, "foo", -1, -1, 0);

Because "foo" is const char*, you have to explicitly convert it to const unsigned char*. Which — strictly adhering to the standard — means allocating a new unsigned char* array and converting the original string byte-by-byte. Having libressl take standard const char* would be a blessing then.

It would be nice if LibreSSL could support SSL_CTX_add_server_custom_ext which is required for example in the nginx-ct module to enable certificate transparency.

I know that LibreSSL was forked from OpenSSL 1.0.1 and the feature was added in 1.0.2 - are there any plans to backport this?

When EVP_CipherInit_ex call with key != NULL and iv == NULL, iv[n] are accessed without NULL check at https://github.com/libressl-portable/openbsd/blob/6e5b37ae2618b181b18de9cb33262259e681fb85/src/lib/libssl/src/crypto/chacha/chacha-merged.c#L108 .

Related backtraces are https://gist.github.com/znz/5cfd09976460a406bb6d#file-backtrace-txt-L69-L72

This issue causes any program linked with libssl.so and libcrypto.so failed connect to sourceforge.net.
Maybe it is not caused by libressl, but sf.net use a wrong configured web server. If so, this issue could be closed with nothing changed.
openssl s_client exit with 1:

 $>> ./apps/openssl/openssl s_client -debug -state -nbio -CAfile /etc/ssl/certs/ca-certificates.crt -connect sf.net:443
CONNECTED(00000003)
turning on non blocking io
SSL_connect:before/connect initialization
write to 0x562b454cd160 [0x562b455b3093] (206 bytes => 206 (0xCE))
0000 - 16 03 01 00 c9 01 00 00-c5 03 03 6d e9 57 e5 90   ...........m.W..
0010 - b3 e0 47 a2 ed 1f a9 2f-13 ec fb 28 ba be 5b 57   ..G..../...(..[W
0020 - 06 44 a8 51 b8 c2 b8 9f-ac 76 f7 00 00 66 c0 30   .D.Q.....v...f.0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 9f 00 6b 00 39   .,.(.$.......k.9
0040 - cc a9 cc a8 cc aa cc 14-cc 13 cc 15 ff 85 00 c4   ................
0050 - 00 88 00 81 00 9d 00 3d-00 35 00 c0 00 84 c0 2f   .......=.5...../
0060 - c0 2b c0 27 c0 23 c0 13-c0 09 00 9e 00 67 00 33   .+.'.#.......g.3
0070 - 00 be 00 45 00 9c 00 3c-00 2f 00 ba 00 41 c0 11   ...E...<./...A..
0080 - c0 07 00 05 00 04 c0 12-c0 08 00 16 00 0a 00 15   ................
0090 - 00 09 00 ff 01 00 00 36-00 0b 00 02 01 00 00 0a   .......6........
00a0 - 00 08 00 06 00 1d 00 17-00 18 00 23 00 00 00 0d   ...........#....
00b0 - 00 1c 00 1a 06 01 06 03-ef ef 05 01 05 03 04 01   ................
00c0 - 04 03 ee ee ed ed 03 01-03 03 02 01 02 03         ..............
SSL_connect:SSLv3 write client hello A
read from 0x562b454cd160 [0x562b455aef43] (5 bytes => -1 (0xFFFFFFFFFFFFFFFF))
SSL_connect:error in SSLv3 read server hello A
write R BLOCK
read from 0x562b454cd160 [0x562b455aef43] (5 bytes => 5 (0x5))
0000 - 16 03 03 00 5f                                    ...._
read from 0x562b454cd160 [0x562b455aef48] (95 bytes => 95 (0x5F))
0000 - 02 00 00 5b 03 03 ca 61-ba 79 51 c4 0c ba 85 44   ...[...a.yQ....D
0010 - 12 02 f5 96 14 23 80 58-a4 0f 1d 19 1d a3 1a 55   .....#.X.......U
0020 - f2 0a f6 71 da 80 20 db-9a a5 90 f6 27 81 88 0a   ...q.. .....'...
0030 - f6 49 8d 87 a2 1a aa a1-06 a7 1c 44 97 4c 84 5a   .I.........D.L.Z
0040 - 16 6a 55 d5 b5 f3 77 c0-14 00 00 13 ff 01 00 01   .jU...w.........
0050 - 00 00 0a 00 04 00 02 00-17 00 0b 00 02 01         ..............
005f - <SPACES/NULS>
SSL_connect:error in SSLv3 read server hello B
140477646259864:error:140050E3:SSL routines:CONNECT_CR_SRVR_HELLO:parse tlsext:ssl_clnt.c:920:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 100 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: DB9AA590F62781880AF6498D87A21AAAA106A71C44974C845A166A55D5B5F377
    Session-ID-ctx: 
    Master-Key: 
    Start Time: 1503100723
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

libressl-portable version:

 $>> git describe --all --long
heads/master-0-g80178a4ba

Since commit f4017f4:

apps_posix.o:apps_posix.c:function app_timer_real: error: undefined reference to 'timespecsub'

build Linux 4.14.0-1-amd64 with gcc 7.2.1

Is timespecsub really exists in linux?

Hi,

openssl command errstr and s_time usage messages are outputed to stdout.
all other commands output to stderr.

# openssl errstr -help > /dev/null
#
# openssl errstr -help 2> /dev/null
-help: bad error code
usage: errstr [-stats]  ...
#

# openssl s_time -help > /dev/null
unknown option -help
# openssl s_time -help 2> /dev/null
usage: s_time 

-connect host:port - host:port to connect to (default is localhost:4433)
-nbio         - Run with non-blocking IO
-ssl2         - Just use SSLv2
-ssl3         - Just use SSLv3
-bugs         - Turn on SSL bug compatibility
-new          - Just time new connections
-reuse        - Just time connection reuse
-www page     - Retrieve 'page' from the site
-time arg     - max number of seconds to collect data, default 30
-verify arg   - turn on peer certificate verification, arg == depth
-cert arg     - certificate file to use, PEM format assumed
-key arg      - RSA file to use, PEM format assumed, key is in cert file
                file if not specified by this option
-CApath arg   - PEM format directory of CA's
-CAfile arg   - PEM format file of CA's
-trusted_first - Use trusted CA's first when building the trust chain
-cipher       - preferred cipher to use, play with 'openssl ciphers'
#

Thanks.

I see you have changed tls_read/tls_write to let 0 passthrough without checks. But is it really smart thing to do?

I remember some SSL2-era security problem caused by inability to differentiate between tcp abort and peer-requested shutdown. Currently 0 from tls_read says it was proper shutdown. Seems now you are changing it to "either it was shut down or we just lost tcp connection". I suppose its possible to check tls_close() error to see if something was off, but it does not seem like improvement.

Related to https://crt.sh/?id=19538258 Blue Coat got signed as CA by Verisign. Since dropping Verisin is not a good idea I like to block the Blue Coat CA/Cert. Blue Coat offers MITM Devices so some users might wish to Block specific Certificates or CAs. Maybe it is also a good choice to disallow such Vendors by default so people/users need to activate them.

After reading the manpage I did not found a way to block a specific sub-CA.
Revoking won't work (I am now the owner of the Certificate) and removing Verisign might not be such a good idea.

In case there is a method I did not spot: please point it out, otherwise I consider it a missing feature/Bug. It would be nice if there is a default-file where you can insert Certificates you like NOT to trust (even if they are valid and signed by a trusted CA).

Kind regards,
Sebastian Rother

Allow access to tlsext_status_cb
This is a feature used in haproxy. Current patch (by me?) is also in OpenBSD ports and does not do what you'd want it to do...

arc4random_buf() segfaults on MIPS32 with uClibc-0.9.33.2 and Linux.

It looks like Libressl is vulnerable to CVE-2016-8610: http://seclists.org/oss-sec/2016/q4/224

As far as I understand libressl tries to stay API compatible with openssl. SSL_CTRL_SET_CURVES seems to be missing compared to openssl though, which makes qt-5.5.0-beta fail here (qt bug with the error: https://bugreports.qt.io/browse/QTBUG-46292 ).

Hi,

Does GOST cipher support little endian only ?
I tested this on hpux(ia64), then I noticed evptest failed.
It seems that test for streebog512 got error.

In evptest.sh.log, I could see this.

Digest mismatch
Got
0000 9f 86 aa 09 a2 5d 94 8e 46 ae bc 29 85 92 55 04
0010 53 b5 07 b7 3a 87 e9 79 a7 f0 be 98 eb 6c f5 15
0020 e8 6e 35 28 55 71 2f 36 d2 6a 4c ac 2a 5f da 3c
0030 cb 81 cd 1b 5c 71 3a ba 8a 1a 1c 4c bf 90 9f 8e
Expected
0000 8e 94 5d a2 09 aa 86 9f 04 55 92 85 29 bc ae 46
0010 79 e9 87 3a b7 07 b5 53 15 f5 6c eb 98 be f0 a7
0020 36 2f 71 55 28 35 6e e8 3c da 5f 2a ac 4c 6a d2
0030 ba 3a 71 5c 1b cd 81 cb 8e 9f 90 bf 4c 1c 1a 8a

You can see that hex dump outputs are overturned.

• [Got] 0000 line is as '9f 86 aa 09 a2 5d 94 8e'
• [Expected] 0000 line is as '8e 94 5d a2 09 aa 86 9f'

With linux, this test succeeds.
I wonder if this works or not in other big endian architecture platform.

Thanks.

in some of the applications i'm involved in writing (as well as the haskell binding i'm still WIP on), I want to provide the option / ability to either issue warning on STDERR or refuse to run outright if the dynamic/shared library isn't recent enough in time (eg, >1 or perhaps 2 years?)

either way, this information seems to only be available in the headers, and not runtime, presently. (or my understanding it out of date :) )

I think the TLS API default configuration is never freed. Also I don't see how the user can access the default configuration in order to have control upon it.

tls_free is related to the context. I think if there is tls_init, there should be tls_free which frees the global config allocated and other things global. But tls_free is related to the context, thus, its name should be like tls_ctx_free().. for me is confusing. In general I think API funcitons related to the context to have name like tls_ctx_...

Also I think the pointer arguments like ctx and others of the api functions should be checked if they were provided by the user as NULL, thus it will make the use of API functions more secure.

Related to the latest scienetific publications TLS 1.0 and 1.1 are also brocken.
I would like to recomment to remove those protocols completly from the LibreSSL-Codebase.

What might happen? Browsers like Firefox will keep using NSS.
Other applications like wget might use TLS 1.0 if the other Server provides just TLS 1.0.
If TLS 1.0 and 1.1 would get removed such connections might not work anymore.

But consider the risk of providing brocken cryptographic protocols to everybody else.
This would be a major step ahead to provide a "secure" protocol (the only one left...).

OpenSource-Projects like wget, lynx and others could get contacted about this matter (of course this would be a bigger effort). The impact on the Client wich manadges for example SAN Storages is low and the effect by providing TLS 1.2 only at the Server side enforces companies to let IE6 rotten in the dust.

All modern Browsers are capable to provide TLS 1.2 and because of the OpenBSD development circle such Changes could get "tested" between releases to see how many applications have Issues.

I consider this Request an "Issue" because TLS 1.0 and 1.1 are brocken and it would be kind if you might could consider to adopt the idea to provide just TLS 1.2.

Hi Team,

This issue was observed while doing source code analysis that:

https://github.com/libressl-portable/openbsd/blob/master/src/lib/libcrypto/evp/e_old.c#L83

DES only supports a 56-bit keysize, which is too small given today'scomputers such as (CWE-327).

I think using a different patent-free encryption algorithm with a larger keysize, such as 3DES or AES.

Request team, to have a look.

Cheers!

tls_config_new
https://github.com/libressl-portable/openbsd/blob/5d28d37770e8d4c018069fae6cb8680c4b322ba6/src/lib/libtls/tls_config.c#L91

and also, tls_init, which calls tls_config_new increments it again. This will results refcount = 2,
https://github.com/libressl-portable/openbsd/blob/5d28d37770e8d4c018069fae6cb8680c4b322ba6/src/lib/libtls/tls.c#L55

Is this a bug or something that I misses to understand?

Hello! In the context of a high concurrency application i'm at the beginning of writing, i'm of course using libtls and friends. I've been trying to understand if

1. TLS can be treated as providing full duplex sockets to the application
2. if TLS the protocol can be full duplex during the bulk of a session, do libressl/libtls provide a full duplex capability to the application (a cursory hunt for locks and mutexes in the code base doesn't give me much clarity here)

many thanks!
(also if this is documented somewhere already please let me know!)
-Carter

https://github.com/libressl-portable/openbsd/blob/master/src/lib/libssl/src/README needs a pass for branding, bug reporting instructions and broken links.

Specifically the links in the following section do not work

Note: For legal reasons, contributions from the US can be accepted only
if a TSU notification and a copy of the patch are sent to [email protected]
(formerly BXA) with a copy to the ENC Encryption Request Coordinator;
please take some time to look at
http://www.bis.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html [sic]
and
http://w3.access.gpo.gov/bis/ear/pdf/740.pdf (EAR Section 740.13(e))
for the details. If "your encryption source code is too large to serve as
an email attachment", they are glad to receive it by fax instead; hope you
have a cheap long-distance plan.

When looking at this file (http://bxr.su/OpenBSD/lib/libcrypto/crypto/getentropy_linux.c), in line 510, there is a memset() to clear the results of the alternative entropy collection from a variable on the stack. If i understand this correctly, this is to make sure that if stack contents leak in another function, it is nothing sensitive. But the variable results is not accessed afterwards, so the compiler might optimize this away. Shouldnt explicit_bzero() be used here?

It cannot operate on https://www.ssllabs.com because OCSP stapled response includes additional subca certs. I think it's even 2 bugs:

• Does not use br->certs when building chain.
• Does not use main_certs when validating br->certs.

This is fixed in openssl 1.0.2 / 1.1.

Problem: https://marc.info/?l=libressl&m=145523606005224&w=4

Fix: https://marc.info/?l=libressl&m=145546713518505&w=4

Lines(in httpd-ssl.conf file):
SSLOpenSSLConfCmd ECDHParameters prime256v1
SSLOpenSSLConfCmd Curves brainpoolP512r1:secp521r1:brainpoolP384r1:secp384r1:brainpoolP256r1:prime256v1
does't work,
how i can set for all vhosts ECDHParameters and Curves?
thanks.
Apache was downloaded from Apachehaus.

Hi,

I noticed that O_DIRECTORY isn't defined in hpux.

...
  CC       openssl-certhash.o
certhash.c: In function 'certhash_main':
certhash.c:661:25: error: 'O_DIRECTORY' undeclared (first use in this function)
certhash.c:661:25: note: each undeclared identifier is reported only once for each function it appears in
*** Error exit code 1

It seems that AIX doesn't have O_DIRECTORY, too.
http://marc.info/?l=openbsd-tech&m=142488231109861&w=2

Could you replace O_DIRECTORY with O_RDONLY ?

Thanks.

Have built many previous versions of LibreSSL on the same system without issue, so it seems the offending commit was introduced in the last release.

Error:

$ make check
Making check in crypto
  CCAS     aes/aes-elf-x86_64.lo
  CCAS     aes/bsaes-elf-x86_64.lo
  CCAS     aes/vpaes-elf-x86_64.lo
aes/vpaes-elf-x86_64.s: Assembler messages:
aes/vpaes-elf-x86_64.s:172: Error: no such instruction: `palignr $12,%xmm5,%xmm5'
aes/vpaes-elf-x86_64.s:298: Error: no such instruction: `palignr $8,%xmm6,%xmm0'
aes/vpaes-elf-x86_64.s:436: Error: no such instruction: `palignr $15,%xmm8,%xmm1'
aes/vpaes-elf-x86_64.s:437: Error: no such instruction: `palignr $15,%xmm8,%xmm8'
aes/vpaes-elf-x86_64.s:442: Error: no such instruction: `palignr $1,%xmm0,%xmm0'
*** Error 1 in crypto (Makefile:7479 'aes/vpaes-elf-x86_64.lo': @echo "  CCAS    " aes/vpaes-elf-x86_64.lo;/bin/sh ../libtool --silent    --...)
*** Error 1 in /usr/local/src/libressl-2.2.2 (Makefile:476 'check-recursive')

System Info:

$ uname -a
OpenBSD <hostname> 5.7 GENERIC#2 amd64
$ dmesg|grep cpu
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Virtual CPU e7da7129d3ee, 3600.46 MHz
cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,RDRAND,HV,NXE,LONG,LAHF,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
cpu0: apic clock running at 1000MHz
acpicpu0 at acpi0

It would be nice if LibreSSL could support SSL_CTX_set1_curves_list which is required to allow a server to specify a list of curves to use for ECDH temporary key generation (for example here: http://mailman.nginx.org/pipermail/nginx-devel/2014-April/005234.html)

I know that LibreSSL was forked from OpenSSL 1.0.1 and the feature was added in 1.0.2 - are there any plans to backport this?

Seems like inet_pton() behaves differently on FreeBSD compared to OpenBSD

FAIL: test 2 ("1") success, want failure
FAIL: test 3 ("1.2") success, want failure
FAIL: test 4 ("1.2.3") success, want failure
FAIL: test 13 ("0xff.0xff.0xff.0xff") success, want failure
FAIL biotest (exit status: 1)

 $>> cat openssl.cfg 
[req]
default_md=sha512
prompt=no
distinguished_name=req_distinguished_name
[req_distinguished_name]
commonName=name

ecc key generated with secp521r1 not works:

 $>> openssl ecparam -genkey -name secp521r1 -out key.key
 $>> openssl req -x509 -new -key key.key -out crt.crt -days 365 -config openssl.cfg

server side:

 $>> openssl s_server -accept 3443 -cert crt.crt -key key.key
Using auto DH parameters
Using default temp ECDH parameters
ACCEPT
ERROR
140466033342104:error:140270C1:SSL routines:ACCEPT_SR_CLNT_HELLO_C:no shared cipher:ssl_srvr.c:1024:
shutting down SSL
CONNECTION CLOSED
ACCEPT

client side exit with 1:

 $>> openssl s_client -state -nbio -CAfile crt.crt -connect localhost:3443
CONNECTED(00000003)
turning on non blocking io
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:error in SSLv3 read server hello A
write R BLOCK
SSL3 alert read:fatal:handshake failure
SSL_connect:failed in SSLv3 read server hello A
140259466426008:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure:ssl_pkt.c:1205:SSL alert number 40
140259466426008:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:ssl_pkt.c:956:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Start Time: 1500551725
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

but ecc key generated with secp384r1 works well:

 $>> openssl ecparam -genkey -name secp384r1 -out key.key
 $>> openssl req -x509 -new -key key.key -out crt.crt -days 365 -config openssl.cfg

server side:

 $>> openssl s_server -accept 3443 -cert crt.crt -key key.key
Using auto DH parameters
Using default temp ECDH parameters
ACCEPT
-----BEGIN SSL SESSION PARAMETERS-----
MFUCAQECAgMDBALALAQABDCsPTVigu6M8evvQ2Xz6D/pf8bkp3ICDB+P8alSva7Z
4VoWirxjfNGF/k6oknW8iJShBgIEWXCbDaIEAgIcIKQGBAQBAAAA
-----END SSL SESSION PARAMETERS-----
Shared ciphers:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305-OLD:ECDHE-RSA-CHACHA20-POLY1305-OLD:DHE-RSA-CHACHA20-POLY1305-OLD:GOST2012256-GOST89-GOST89:DHE-RSA-CAMELLIA256-SHA256:DHE-RSA-CAMELLIA256-SHA:GOST2001-GOST89-GOST89:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA256:CAMELLIA256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA256:CAMELLIA128-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA:EDH-RSA-DES-CBC-SHA:DES-CBC-SHA
CIPHER is ECDHE-ECDSA-AES256-GCM-SHA384
Secure Renegotiation IS supported

client side:

 $>> openssl s_client -state -nbio -CAfile crt.crt -connect localhost:3443
CONNECTED(00000003)
turning on non blocking io
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:error in SSLv3 read server hello A
write R BLOCK
SSL_connect:SSLv3 read server hello A
depth=0 CN = name
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:error in SSLv3 read server session ticket A
read R BLOCK
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
read R BLOCK
---
Certificate chain
 0 s:/CN=name
   i:/CN=name
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIBSjCB0QIJAJGUMcK9SyDuMAoGCCqGSM49BAMEMA8xDTALBgNVBAMMBG5hbWUw
HhcNMTcwNzIwMTE1ODM0WhcNMTgwNzIwMTE1ODM0WjAPMQ0wCwYDVQQDDARuYW1l
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE+vYfKTf/r0f4ba7Iu0LNW7v0OZhJbOvn
falDl/b6GqPf/EpCAMIrdVsEFcl+YQbtVlyuJD1UWpoOLSoz5xSiFDxoky0WZ0TL
iNgvWAR/dIK2f/GTfqIXYjQpweKVh+o2MAoGCCqGSM49BAMEA2gAMGUCMCgaMr/T
ftYVk3IZMw++l9hh+r4ng2QCdisULm1WtdukIlwCsL1ddRbC5WY8NWZL3QIxAMNr
/waH/TY8Y8Hpm8/ECoh+mA8irrv9aZhNVMOMG30MyQ+F3yq1CVRRFyex2y3gAQ==
-----END CERTIFICATE-----
subject=/CN=name
issuer=/CN=name
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 833 bytes and written 342 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 384 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: 038331A97E4DE0C12247AF503C06D5AD1E0C338A5739E304D89E07BF9F00E96B
    Session-ID-ctx: 
    Master-Key: AC3D356282EE8CF1EBEF4365F3E83FE97FC6E4A772020C1F8FF1A952BDAED9E15A168ABC637CD185FE4EA89275BC8894
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 51 80 6e 5a 68 52 fc 84-e3 15 66 8a bc 56 c8 e9   Q.nZhR....f..V..
    0010 - 36 47 be 05 7c 4e 75 f3-6a 04 c2 48 78 31 fc d6   6G..|Nu.j..Hx1..
    0020 - db 18 67 61 3f 6c b6 92-21 ea f4 75 51 d0 9e 4b   ..ga?l..!..uQ..K
    0030 - f9 0c 61 f4 e7 5e 99 ca-fe 6c 0d ae 6a 9a 57 12   ..a..^...l..j.W.
    0040 - 3e c1 6b 4c 44 87 20 88-a8 5f 85 44 43 98 e9 11   >.kLD. .._.DC...
    0050 - 4e 4a 3d ad d5 55 55 08-35 82 5f 10 c6 39 59 15   NJ=..UU.5._..9Y.
    0060 - eb 7c 87 05 89 d1 10 53-5a c7 b1 0c 9b eb c1 3b   .|.....SZ......;
    0070 - 6d c6 c9 4d 00 e4 c4 b5-13 5f 73 c7 e0 79 bc f8   m..M....._s..y..
    0080 - e0 e5 09 ec 3d 8c b5 13-6c d5 9b 4a c7 b9 5c 01   ....=...l..J..\.
    0090 - fd 25 56 71 a0 c2 aa fa-19 d5 f4 1d bb f3 c7 64   .%Vq...........d

    Start Time: 1500551949
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

libressl-portable git version, configure option:

--enable-shared
--enable-static
--enable-nc
--enable-asm
--with-pic

SSL_CTX_set_cert_store does not increment the reference count of the store object. This a trap for the unwary as OpenSSL has been inconsistent in this regard. Some "set_foo" routines will increment the reference, others won't, and my habit has always been to examine the implementations. Newer APIs use the set0_foo and set1_foo, which is a much nicer contract that allows me to relax a little more.

I've been using a fake SSL_CTX_set1_cert_store macro in my projects for a couple of years now which only incremented the reference if SSL_CTX_set_cert_store failed to. (I was afraid somebody might "fix" the routine by incrementing the reference count, causing a leak in my wrapper.) But now that OpenSSL objects are going opaque I can't test the reference count anymore.

OpenSSL is also adding SSL_CTX_set1_cert_store:
openssl/openssl#1755
openssl/openssl#1734

If the supplied buffer is smaller than the required space, LibreSSL's OBJ_obj2txt() fails with 0 return. This contradicts the documentation:

OBJ_obj2txt() converts the ASN1_OBJECT a into a textual representation. The representation is written as a NUL terminated string to buf. At most buf_len bytes are written, truncating the result if necessary. The total amount of space required is returned. If no_name is 0 and the object has a long or short name, then that will be used, otherwise the numerical form will be used.

Test code:

#include <stdio.h>
#include <openssl/objects.h>

int main(void)
{
	char buf[10];
	int ret;
	ASN1_OBJECT *obj;
	const char *oid = "0.1.2.3.4.5.6.7.8.9"; /* 19 characters + \0 */

	obj = OBJ_txt2obj(oid, 1);
	if (!oid)
		return 1;

	ret = OBJ_obj2txt(buf, sizeof buf, obj, 1);
	printf("OBJ_obj2txt() returned %d, buf = %s\n", ret, buf);

	ASN1_OBJECT_free(obj);
}

OpenSSL 1.1.0:

OBJ_obj2txt() returned 19, buf = 0.1.2.3.4

LibreSSL GitHub master:

OBJ_obj2txt() returned 0, buf = 0.1.2.3.4

I'd expect OBJ_obj2txt() to always return the length of the resulting string (excluding the NUL terminator) so that I can retry with a larger buffer, as OpenSSL's does.

Hi,
openssl pkeyutl -verify command seems returns exit status always 1.
it should return exit status 0 when pkeyutl -verify succeeds.

# openssl_bin=/work/github/portable/apps/openssl
# $openssl_bin pkeyutl -verify -in pkeyutl.dat -sigfile pkeyutl.sig -inkey genpkey_rsa.pem
Signature Verified Successfully
# echo $?
1
#
# $openssl_bin pkeyutl -verify -in pkeyutl.dat -sigfile pkeyutl.sig -inkey genrsa_aes256.pem
Enter pass phrase for genrsa_aes256.pem:
Signature Verification Failure
# echo $?
1
#

Thanks.

I have a testcase where EOF from SSL_read() will be converted to random error because the random error was in global libssl error stack. The problem is that libssl does not touch error stack when returning 0.

The actual testcase was actually on openssl 1.1, does not reproduce on libressl or openssl 1.0.1/2.

But the same coding is visible in libressl too. Should libtls be more robust against it? Call ERR_clear_error() in tls_read() / tls_write() / tls_handshake() ?

Short version: Please import this change from OpenSSL
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=4e05aedbcab7f7f83a887e952ebdcc5d4f2291e4

It appears LibreSSL never imported the 2014 OpenSSL fix above. See https://rt.openssl.org/Ticket/Display.html?id=3560 for the original report which includes repro instructions. Note you may need an OpenSSL 1.0.2 build for the s_client half of the repro steps. Unless you all backported it, OpenSSL 1.0.1, which you're based on, does not print the peer signature algorithm in s_client.

The failure mode is LibreSSL servers which use SNI are only capable of signing SHA-1 hashes when producing the ServerKeyExchange. Such servers will break against clients which require stronger ServerKeyExchange signatures. (I noticed this looking for SHA-1-requiring servers in the wild. Turned out some of it was because of LibreSSL.)

PS: The proper fix here is actually to revise the state-tracking so peer sigalgs are not on the CERT struct. The latest revisions of both OpenSSL and BoringSSL have moved it elsewhere, so that may be some follow-up cleanup to be done here. But that code has changed significantly since 1.0.1 so importing the fix first may be simplest.

Found this while reading the code, not through testing. The reference count on the ctx structure is incremented for the assignment of ctx to s->initial_ctx but this is not decremented on the code path through the err: label. The increment/decrement is matched for the assignment of ctx to s->ctx.

ssl_lib.c.

The header bn.h defines the function BN_print differently depending whether bio.h is included:

#ifdef HEADER_BIO_H
int BN_print(BIO *fp, const BIGNUM *a);
#else
int BN_print(void *fp, const BIGNUM *a);
#endif

Only one type is allowable for BN_print, the type with which the function is defined (C11 6.2.7:2 “All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined”). The types void * and BIO * are not compatible, and neither are the types of functions taking one or the other as argument.

Does anyone know what problem the hack above is supposed to solve and whether it is still useful?

I asked a question on StackOverflow recently but this may be an actual bug so I thought I'd report it here too.

When creating a CSR, the subject line seems to vary depending on the order of parameters:

For example:

$ openssl req -new -key my.key -out my.csr \
    -subj="/C=UK/L=London/O=Org/OU=Unit/CN=my.domain/[email protected]"

Gives

Subject: C=UK, L=London, O=Org, OU=Unit, CN=my.domain/[email protected]

Which doesn't look right anyway. I don't know if emailAddress is a valid field name, however it is requested when entering the field using the subject prompt in LibreSSL 2.2.7 on OSX, installed via brew, and that will give you the same output.

Further, if you move emailAddress to the beginning of the subject, it then becomes comma seperated:

$ openssl req -new -key my.key -out my.csr \
    -subj="/[email protected]/C=UK/L=London/O=Org/OU=Unit/CN=my.domain"

Subject: [email protected], C=UK, L=London, O=Org, OU=Unit, CN=my.domain

Not sure how important it is, so long as the subject line doesn't change, the signature will be valid.

For example on this line one of the BN_new() might not be freed. There are other examples. Are patches needed? If not close this and sorry for the noise.

(PS: I have a Dockerfile with this config based on Ubuntu that I can share if necessary)

This was tested initially on LibreSSL Portable but reproduces with the system LibreSSL on OpenBSD 5.9, hence the report here. That it reproduces on OpenBSD makes me wonder if this is a "feature" rather than a "bug". This doesn't reproduce on a current OpenSSL, either the latest 1.0.1 or 1.0.2 releases, for what that's worth.

LibreSSL built with a custom --with-openssldir=/usr/local/etc/libressl doesn't propagate to s_client, and you have to pass the -CAfile manually to create an error-free connection.

openssl s_client -connect github.com:443

CONNECTED(00000003)
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0

---
[snip]

---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
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-AES128-GCM-SHA256
    Session-ID: xyz
    Session-ID-ctx:
    Master-Key: xyz
    Start Time: 1466208586
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)

---

Passing the -CAfile manually does produce the expected end result:

openssl s_client -connect github.com:443 -CAfile /usr/local/etc/libressl/cert.pem

CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA
verify return:1
depth=0 businessCategory = Private Organization, 1.3.6.1.4.1.311.60.2.1.3 = US, 1.3.6.1.4.1.311.60.2.1.2 = Delaware, serialNumber = 5157550, street = "88 Colin P Kelly, Jr Street", postalCode = 94107, C = US, ST = California, L = San Francisco, O = "GitHub, Inc.", CN = github.com
verify return:1

---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
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-AES128-GCM-SHA256
    Session-ID: xyz
    Session-ID-ctx:
    Master-Key: xyz
    Start Time: 1466208734
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

Unsure if related but a grep for OPENSSLDIR in OpenSSL 1.0.2h & LibreSSL 2.3.6 shows OpenSSL stores the custom openssldir passed during configure but LibreSSL seems to have discarded it in favour of the default path:

/usr/local/opt/openssl/include/openssl/opensslconf.h:#if defined(HEADER_CRYPTLIB_H) && !defined(OPENSSLDIR)
/usr/local/opt/openssl/include/openssl/opensslconf.h:#define OPENSSLDIR "/usr/local/etc/openssl"
/usr/local/opt/libressl/include/openssl/opensslconf.h:#if defined(HEADER_CRYPTLIB_H) && !defined(OPENSSLDIR)
/usr/local/opt/libressl/include/openssl/opensslconf.h:#define OPENSSLDIR "/etc/ssl"

Hi,
I've adapted "libressl-2.0.2/tests/explicit_bzero.c" to test some implementations of explicit_bzero.
Compiling this test file with "gcc49 -O1 -flto -DELF_HOOK_IMPL gistfile1.c" on FreeBSD optimizes away the explicit_bzero calls and the __explicit_bzero_hook symbol, resulting in a test failure. This is the current implementation used by OpenBSD and LibreSSL. I don't know if this is caused by toolchain advances or differences in weak symbol semantics. On OpenBSD 5.5 the test works fine with the system compiler and GCC 4.8 from ports.

I've fixed the elf hook implementation by removing the default implementation of __explicit_bzero_hook and putting the call to __explicit_bzero_hook behind an if check.

Another fix could be to use one of the VOLATILE_{1,2,3}_IMPL implementations as they rely on portable C semantics.

The compatibility function DH_set0_key added in LibreSSL 2.7.0 has a different (possibly unwanted) behaviour from OpenSSL 1.1.0. In OpenSSL, it is perfectly OK to add just add pub_key to otherwise empty DH structure, e.g. this is OK:

dh = DH_new();
BIGNUM pub_key;
BN_hex2bn(pub_key, "02");
DH_set0_key(dh, pub_key, NULL);

In LibreSSL, this would fail to set the internal structures because dh->priv_key == NULL.

I don't think having quirks like this is desirable for users of both libraries.

The anti-pattern free (p); if (p != q) free (q); is used in two places in ssl_lib.c:

https://github.com/libressl-portable/openbsd/blob/c81daac11c5df39dd5215c024c103b54f054cbf6/src/lib/libssl/src/ssl/ssl_lib.c#L507

https://github.com/libressl-portable/openbsd/blob/c81daac11c5df39dd5215c024c103b54f054cbf6/src/lib/libssl/src/ssl/ssl_lib.c#L576

The use of p in p != q is a use-after-free (probably originally written to avoid a double-free, which is only a specialized kind of use-after-free). All uses-after-free are bad. The boolean condition p != q should be computed before freeing p.

Plex Media Player (which is based on libmpv based on ffmpeg built with libtls) uses URLs like this:
https://192.168.1.5:32400/video/:/transcode/universal/start?hasMDE=1&...

And mpv gives the following error:
2018-02-11 15:56:06 [ ERROR ] PlayerComponent.cpp @ 589 - ffmpeg: tls: server name not specified

I believe this's because the unneeded check for a 2nd colon in https://github.com/libressl-portable/openbsd/blob/master/src/lib/libtls/tls_util.c

/* Find the port seperator. */
if ((p = strchr(p, ':')) == NULL)
	goto done;

/* If there is another separator then we have issues. */
if (strchr(p + 1, ':') != NULL)
	goto done;

Following this link, LibreSSL's PRNG is not safe and can provide the same 'random' bytes when called from a fork, compared to a call in the original program.

LibreSSL uses arc4random for random number generation. The way this has been implemented, i.e. replacing the calls to RAND_bytes and RAND_pseudo_bytes by a call to arc4random, removed the support for a custom RAND engine, because there is no code anymore which calls the functions of the RAND engine provided by ENGINE_set_RAND and ENGINE_set_default(e, ENGINE_METHOD_RAND).

Was the removal of RAND engine support intended?

OpenVPN (latest version) segfaults when used with LibreSSL v2.5.1 / v2.5.2.
Everything works fine with v2.5.0 and v2.4.5.

gdb trace (v2.5.2):

Temporary breakpoint 1, main (argc=12, argv=0x7ffffffae8) at openvpn.c:367
367	    return openvpn_main(argc, argv);
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0000007fb7f3be40 in SSL_CTX_ctrl (ctx=ctx@entry=0x7ffffff360, cmd=cmd@entry=32, larg=larg@entry=0, parg=parg@entry=0x0) at ssl_lib.c:1170
1170			return (ctx->internal->options|=larg);
(gdb) backtrace
#0  0x0000007fb7f3be40 in SSL_CTX_ctrl (ctx=ctx@entry=0x7ffffff360, cmd=cmd@entry=32, larg=larg@entry=0, parg=parg@entry=0x0)
    at ssl_lib.c:1170
#1  0x000000000046132c in tls_ctx_client_new (ctx=ctx@entry=0x7ffffff360) at ssl_openssl.c:119
#2  0x000000000045ba4c in init_ssl (options=options@entry=0x7fffffebd8, new_ctx=new_ctx@entry=0x7ffffff360) at ssl.c:612
#3  0x000000000041a510 in do_init_crypto_tls_c1 (c=0x7fffffebd8) at init.c:2430
#4  do_init_crypto_tls (c=c@entry=0x7fffffebd8, flags=3) at init.c:2533
#5  0x000000000041d15c in do_init_crypto (flags=<optimized out>, c=0x7fffffebd8) at init.c:2776
#6  init_instance (c=c@entry=0x7fffffebd8, env=env@entry=0x0, flags=4, flags@entry=0) at init.c:4018
#7  0x000000000041ddcc in init_instance_handle_signals (c=0x7fffffebd8, env=0x0, flags=0) at init.c:3829
#8  0x00000000004327e4 in tunnel_point_to_point (c=0x7fffffec28) at openvpn.c:70
#9  openvpn_main (argc=12, argv=0x7ffffffae8) at openvpn.c:284
#10 0x0000007fb7c39d88 in __libc_start_main (main=0x408840 <main>, argc=12, argv=0x7ffffffae8, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=<optimized out>) at libc-start.c:287
#11 0x0000000000408870 in _start ()

Haven't tried to reproduce this on any architecture other than armv7l.