Compile Flags vs Configuration Options
In case you missed it - an OpenSSL vulnerability in the implementation of the TLS Heartbeat Extension has been making the rounds. For more information see http://heartbleed.com/.
One of the possible mitigation steps is to recompile OpenSSL with the -DOPENSSL_NO_HEARTBEATS option to disable the vulnerable extension.
Why does a system administrator have to recompile the library to disable an extension? Why isn't there a configuration option? Would have made a short term remediation much easier.
My best guess that this is a high performance library and as a library by it's nature does not have a configuration file as services do. Searching through Apache mod_ssl and Nginx HttpSslModule documentation I didn't see anything that would allow me to disable the Heartbeat functionality via configuration. Shouldn't this be an option?
-EDIT-
To clarify, everyone affected needs to revoke and replace affected SSL certificates. The primary problem here is that the vulnerability allowed anyone to pull 64 KB of application memory from a vulnerable server. This could have easily been addressed with a configuration option. Having to revoke and replace SSL certificates is a secondary consequence of this vulnerability, among other concerns with regards to what type of data (usernames, passwords, session info...) could have been leaked from application memory.
-EDIT2-
To clarify - by configuration I don't mean the configuration when compiling OpenSSL. I meant configuration in the web server. For instance, with apache mod_ssl, I can configure a range of options that affect SSL, such as the Cipher Suites available.
I don't have knowledge of the programmers' state of mind when they made this decision but yes - a library is not going to be used in a well-defined scenario or two, it's going to be used however someone coded the main() to call it
If you really want to disable an option then compiling it out seems to me to be the best and safest route.
Compile Flags vs Configuration Options - TLS Heartbeat
That's easy... Its detailed on the OpenSSL wiki under Configuration Options at Compilation and Installation: at configuration time, just add -DOPENSSL_NO_HEARTBEATS .
So you seem to have found the configuration option. The configuration option gets written to <openssl install>/include/openssl/opensslconf.h , so it flows to compile time, too.
That only leaves runtime (see below for that).
Why does a system administrator have to recompile the library to disable an extension?
You should not have to. Your distribution should provide it for you. But they will likely provide it in their build.
Sometimes you may need to find it from a "Personal Archive", like a PPA on Ubuntu.
(Ubuntu does some dumb things on occasion, like disabling TLS 1.1 and 1.2 in OpenSSL and disabling TLS 1.1 and 1.2 in OpenJDK. Its 2015, and they still have not been enabled).
Why isn't there a configuration option?
There is, and its published. You seem to have found it.
There's also a runtime option:
openssl-1.0.2a$ grep -R -A 1 -i heartbeat *
...
include/openssl/tls1.h:# define SSL_set_tlsext_heartbeat_no_requests(ssl, arg)
include/openssl/tls1.h: SSL_ctrl((ssl),SSL_CTRL_SET_TLS_EXT_HEARTBEAT_NO_REQUESTS,arg,NULL)
...
And:
include/openssl/ssl.h:# define SSL_heartbeat(ssl)
include/openssl/ssl.h: SSL_ctrl((ssl),SSL_CTRL_TLS_EXT_SEND_HEARTBEAT,0,NULL)
Would have made a short term remediation much easier.
The one that chaps my ass is the TLS_FALLBACK_SCSV . You cannot disable it at configuration time, at compile time, or at runtime. Its more insecure browser crap that leaked its way into other user agents and software....
If you start working on compiling openssl, I would suggest to compile a "more secure" version of openssl for your needs. Not only disable heartbeat (-DOPENSSL_NO_HEARTBEATS) but also disable all unnecessary options in openssl.
链接地址: http://www.djcxy.com/p/19864.html上一篇: 对于renderDataTable，使用R Shiny中的TableTools for DataTables
下一篇: 编译标志与配置选项