Are Apache Tomcat servers using Tomcat Native & APR vulnerable to the HeartBleed OpenSSL bug, or does this layer insulate them? http://tomcat.apache.org/native-doc/

HeartBleed OpenSSL bug information: http://heartbleed.com/

On my Apache Tomcat server, I have:

  • A vulnerable version of OpenSSL
  • Built and installed APR
  • Built and installed Tomcat Native using --with-apr and --with-ssl
  • Tomcat is handling requests directly. A Connector on port 443 is configured with attributes SSLEnabled, SSLProtocol, SSLCipherSuite, SSLCertificateFile, SSLCertificateKeyFile, SSLCertificateChainFile
    • SSLProtocol="-ALL +SSLv3 +TLSv1"


  • Do versions of Tomcat, APR, or Tomcat Native have any affect on vulnerability?
  • Do SSLProtocol or SSLCipherSuite values affect vulnerability?
  • Confirmed my app was vulnerable according to filippo.io/Heartbleed After upgrading OpenSSL, simply restarting Tomcat eliminated the vulnerability. Re-compiling APR or Tomcat Native was not necessary.
    – Arlo
    Apr 8, 2014 at 23:27
  • This is a really important question. Tomcat is installed by a great many apps on public facing nets (e.g. all the Atlassian products, for example) Apr 9, 2014 at 13:57
  • If someone is interested, I've managed to build a version of tc-native for Windows X64 uisng OpenSSL 1.0.1g. I couldn't find any updated binaries. db.tt/VVeDe4t7 Apr 10, 2014 at 7:17
  • For those using binary builds, there's a Bug regarding updating the Tomcat Native builds: issues.apache.org/bugzilla/show_bug.cgi?id=56363
    – Arlo
    Apr 10, 2014 at 21:35

4 Answers 4


According to the document you linked to, the APR connector

  • Uses OpenSSL for TLS/SSL capabilities (if supported by linked APR library)

Therefore, it would be reasonable to assume that the Tomcat Native Library would be vulnerable to the Heartbleed bug. However, the conditions are different, because Tomcat is written in Java, and Java has its own allocation system (the famous garbage collector) which obtains memory from the OS by huge blocks, quite apart from the zones where OpenSSL obtains its blocks.

Thus, the heartbleed buffer overrun is unlikely to reveal any secret information which exists as Java-based object. It may, however, obtain information which is allocated from the same heap as where OpenSSL obtains its own buffers. In particular, it is possible that the vulnerability may reveal part or all of the private key used by OpenSSL itself.

  • Just because OpenSSL is linked in doesn't mean that it's exploitable via the Heartbleed bug. Maybe it is, but your answer seems cautionary and speculative rather than authoritative. Apr 8, 2014 at 18:16
  • 3
    The linked document is pretty clear about the point of APR+native being to do the SSL/TLS with OpenSSL, from which it is pretty clear that the code chunk in which the bug is will be invoked. Apr 8, 2014 at 18:47
  • @ThomasPornin Can a static vulnerability analysis be %100 reliable, or should we focus on how to identify potential problem sites and how to update them? Apr 9, 2014 at 14:51

I've got a tomcat 7.0.29 server on windows that is showing up as vulnerable on the qualys heartbleed scans. It's using APR with this connector configuration in server.xml:

Connector protocol="org.apache.coyote.http11.Http11AprProtocol"
port="443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"



Here's a link to tcnative-1.1.29 binaries for Windows complied against apr-1.5.0, openssl-1.0.1g. This is complied against VC 2008, so you will need the Microsoft Visual C++ 2008 Redistributable for Windows 2003 or XP. The files from Juan Calero didn't include win32 and were complied against VC 2010. One or the other might serve your proposes better. You just need to stop tomcat, replace tcnative-1.dll then start tomcat.

  • Any reassurances that the patch is safe?
    – TildalWave
    Apr 10, 2014 at 18:30
  • I would understand not wanting to use a DLL complied by a random guy on the internet. I provided the scan results from clamav in the zip. I've tested the library using the hb-test.py script.
    – user44127
    Apr 10, 2014 at 23:05
  • tcnative compiled against openssl 1.0.1g from Apache folks: people.apache.org/~mturk/native/1.1.30 Apr 13, 2014 at 23:39

I believe tomcat is not vulnerable to heartbleed out of the box.

Yes, the APR library is linked and SSLEngine is on.

<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />

But if you look at the server.xml config file of a default tomcat deployment, it's SSL connector uses JSSE not the APR library.

<!-- Define a SSL HTTP/1.1 Connector on port 8443
     This connector uses the BIO implementation that requires the JSSE
     style configuration. When using the APR/native implementation, the
     OpenSSL style configuration is required as described in the APR/native
     documentation -->
<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
           maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
           clientAuth="false" sslProtocol="TLS" />

So it shouldn't be exploitable via Heartbleed. Unless you manually changed the SSL connector to use APR, I think it's safe to say, you are not vulnerable.

Speaking of which do you know of any offline tester for heartbleed?



Alex L.

  • Courtesy of Jared Stafford: rehmann.co/projects/heartbeat/ssltest.py Apr 11, 2014 at 6:30
  • Apache apparently disagrees: issues.apache.org/bugzilla/show_bug.cgi?id=56363 Apr 13, 2014 at 23:38
  • 1
    It is vulnerable if you enable APR Connector for HTTPS. But Out Of The Box it's not enabled. It's the difference between org.apache.coyote.http11.Http11Protocol AND org.apache.coyote.http11.Http11AprProtocol. And some other config changes since you need to update other values if you switch to APR. And read the Native/ARP docs for that.
    – Alex
    Apr 14, 2014 at 7:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .