1

This question is kind of related to this Why is ALPN not supported by my server?

But in my case, the same test does say that ALPN is supported even if I am not using OpenSSL1.0.2 and only OpenSSL1.0.1t

I am currently using Apache2.4.25 with h2 activated. But it still bothers me that ALPN is supported even if my OpenSSL is supposed to not support it?

My http2.conf in conf-enabled:

Protocols h2 h2c http/1.1
H2Push          on  
H2PushPriority  *                       after  
H2PushPriority  text/css                before  
H2PushPriority  image/jpeg              after   32  
H2PushPriority  image/png               after   32  
H2PushPriority  application/javascript  interleaved
SSLProtocol all -SSLv2 -SSLv3  
SSLHonorCipherOrder on  
SSLCipherSuite 'EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384       EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS'

Output from LDD:

╰─➤  ldd /usr/sbin/apache2                                                                                                                                                 1 ↵
linux-vdso.so.1 (0x00007ffc4d593000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fa1c2492000)
libaprutil-1.so.0 => /usr/lib/x86_64-linux-gnu/libaprutil-1.so.0 (0x00007fa1c2269000)
libapr-1.so.0 => /usr/lib/x86_64-linux-gnu/libapr-1.so.0 (0x00007fa1c2034000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa1c1e17000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa1c1a6c000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fa1c1867000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa1c165f000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fa1c1428000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa1c1224000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fa1c0ffb000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa1c29a5000)

Counterquestions is appreciated!

2

The ldd output doesn't include any reference to libssl.so. This indicates that your Apache uses a statically linked version of the SSL library which means that the OpenSSL is included in the Apache2 binary file.

So, your Apache2 does not use the SSL library on your system.

2
  • So, does that mean that apache has ALPN support? Does "Protocols h2 h2c http/1.1" have anything to do with it? – Orphans Mar 16 '17 at 7:49
  • Your Apache has ALPN support if it has been statically linked with OpenSSL 1.0.2 version. You might be able to find details on your Apache by looking at the information provided by the packager. – Tero Kilkanen Mar 16 '17 at 13:11
1

I cannot find any other explanation than suggesting you might have two versions of openSSL installed (or the test results are wrong).

Apache2's mod_http2 is based on nghttp2, and its docs (https://nghttp2.org/documentation/nghttpx-howto.html#alpn-support) state:

ALPN support

ALPN support requires OpenSSL >= 1.0.2.

Curiously, the release notes for 1.0.1t (https://www.openssl.org/news/openssl-1.0.1-notes.html) mention:

Modify behavior of ALPN to invoke callback after SNI/servername callback, such that updates to the SSL_CTX affect ALPN.

Tracking down that message leads to https://github.com/openssl/openssl/commit/1316ca80f4e1dc9339572c780d495f995fe0bad0.

That however seems to only have contributed code to 1.1.0 - I could not find evidence of its changes in 1.0.1t.

In theory, ALPN and NPN are very closely related (https://hpbn.co/transport-layer-security-tls/#application-layer-protocol-negotiation-alpn) - the main difference between the two being who announces the protocols. But I simply cannot find a logical explanation to your findings, so have to ask if you are certain of your premises.

You can serve HTTP/2 without ALPN (I checked using the test/tool you linked to), but I cannot find anything to explain why ALPN would be shown as supported.

The only other lead I could find is a bug report for RH, where this issue is discussed at some length:

https://bugzilla.redhat.com/show_bug.cgi?id=1276310

There are suggestions that the RH team may do something about it, but I don't see any clear indication of a backport of ALPN into 1.0.1. And don't know whether a RedHat related discussion is relevant in your case.

10
  • Could this in conf-enabled/http2.conf be the answer? "Protocols h2 h2c http/1.1" – Orphans Mar 15 '17 at 10:00
  • There is only one version of OpenSSL installed. so the only exaplanation is that the test is wrong. But it has been wrong for month and should'nt a quite big company have verified that their test works correctly? – Orphans Mar 15 '17 at 10:03
  • I unfortunately don't have anything I can use to test, so it is a bit hard to answer. It might be worth using curl (e.g. curl --http2) or a browser (see icing.github.io/mod_h2/howto.html) to confirm what the check returns. If these agree that ALPN is available, then I think it might be necessary to look a bit further into your apache build, and how it was compiled. – iwaseatenbyagrue Mar 15 '17 at 10:14
  • Have you checked with ldd which libraries Apache uses? – Tero Kilkanen Mar 15 '17 at 10:20
  • @iwaseatenbyagrue I can confirm that HTTP/2 is running from a webbrowser and via the apache access.log. So HTTP/2 is runnig fine. – Orphans Mar 15 '17 at 11:06
0

It seems like apache 2.4.25 from the testing repo is compiled toghether with libssl 1.0.2, that explains why the server has ALPN support even if OpenSSL1.0.2 is not installed on the system.

0

I can't comment on the ALPN question directly, but ldd shouldn't be used on /usr/sbin/apache2 unless apachectl -M indicates that ssl_module or http2_module are static instead of shared (shared being the default for most modules). use ldd $(locate mod_ssl.so) resp. ldd $(locate mod_http2.so) instead. From there it should be possible to find out against which version you are really linked.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.