I am using apache2 server runing on a Ubuntu Server 12.04 LTS.
In my apache2 conf file there is a host that looks like this.
IfModule mod_ssl.c>
VirtualHost *:443>
//Every configuration for the virtual host working fine.
/VirtualHost>
/IfModule>
I avoid using the "minor" sign since SO does not display the line containing it.
I cannot read "OpenSSL" anywhere. So my intuition says that I am not using it at all. So I should not worry about Heart bleed open SSL bug.
Am I right?
Thanks in advance.
From the command prompt do:
openssl version
OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable
Your config is using mod_ssl. Mod SSL is OpenSSL built for Apache.
If your server is public facing you can try something like this tool. http://filippo.io/Heartbleed/
Related
I have issues when to make my apache server uses TLS1.2. I respect all recommended configuration (ssl.conf, virtuals, ciphers ...) but apache is all the time using TLS1.0. I suspect the version of openssl to be the root cause.
Environment : RHEL 7
openssl version : OpenSSL 1.0.1e-fips
Apache version : Apache/2.4.6
I have this message on browser dev tools even though configuration seems to be ok :
The connection to this site is encrypted and authenticated using TLS 1.0, ECDHE_RSA, and AES_256_CBC with HMAC-SHA1.
TLS 1.0 is obsolete. Enable TLS 1.2 or later.
AES_256_CBC is obsolete. Enable an AES-GCM-based cipher suite.
can you help on this please ?
Make sure you have restarted apache.
And, make sure this line is added, and make sure all other SSLProtocol are commented using # at the start of the line, or removed:
SSLProtocol -all +TLSv1.2 +TLSv1.3
Or, if your version of OpenSSL doesn't support TLSv1.3:
SSLProtocol -all +TLSv1.2
I absolutely recommend you to update to the latest version of Apache (2.4.46 at the time of this post), and OpenSSL 1.1.1.
You can use SSL Labs to test your website's SSL conf.
Next:
AES_256_CBC is obsolete. Enable an AES-GCM-based cipher suite.
For the above, you can test your site on SSL Labs, and see the ciphers that are green and orange, and you can implement them by using https://testssl.sh/openssl-iana.mapping.html for help
I want to setup SSL certificate on tomcat, specification of my server:
OS: ubuntu 18.04 LTS
tomcat: 9.0.31
java: 1.8.0_242
I have these files:
xyz.key
xyz.ca-bundle
xyz.crt
I want to run tomcat on port 443 although I Know I can change port by using server.xml file.
By using the above files I can easily setup ssl in apache, But my question is which type of file format I should have in order to setup ssl in tomcat server and if I need some other format then how should I convert these files ?
Question is pretty unclear, but I assume what you're trying to do is run Tomcat standalone, not with Apache Httpd as a proxy. In that case, the easiest and best thing to do is to upgrade to a modern version of Java. Java 9 and later support PKCS12, which is easier than using JKS, so you should upgrade, either to 11 (the current LTS release) or 14 (current release).
Once that is done, you can use this tool to generate a CSR and save a key and help set up your configuration. It might be easier than doing this by editing files.
I'm trying to recreate the heartbleed attack on a localhost apache server. I'm running xampp 1.8.3-2 on my ubuntu, and I want to degrade my OpenSSL version from 1.0.1e to 1.0.1b. I found out some info on the net on how to do this on windows, but nothing about linux - only how to update obviously. What are the files I need to replace, and where can I find the files for 1.0.1b?
Thanks In advance!
I read on various forums regarding POODLE vulnerability in SSLv3. It is recommended to disable SSLv3 and support TLS_FALLBACK_SCSV on servers.
How to enable support of TLS_FALLBACK_SCSV on apache2.2?
Upgrade to the latest version of openssl, which automatically supports TLS-FALLBACK-SCSV. Apache will use that.
From https://www.openssl.org/news/secadv_20141015.txt :
OpenSSL 1.0.1 users should upgrade to 1.0.1j.
OpenSSL 1.0.0 users should upgrade to 1.0.0o.
OpenSSL 0.9.8 users should upgrade to 0.9.8zc.
Debian and other Distributions are deploying backports of the TLS-FALLBACK-SCSV update on OpenSSL.
Restart your Apache after the update.
Check your server
SSL Labs will check whether you support TLS_FALLBACK_SCSV.
Notice how https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=74.125.239.96&hideResults=on notes "TLS_FALLBACK_SCSV supported"
It shouldn't be necessary to do both; TLS_FALLBACK_SCSV is a mechanism to prevent downgrade attacks, but if your server does not allow SSLv3 (or v2) connections it is not needed (as those downgraded connections would not work)
Edit (to incorporate feedback):
Technically TLS_FALLBACK_SCSV is still useful with SSL disabled, because it helps avoid the connection being downgraded to TLS < 1.2. But this is unnecessary to defend against POODLE, since the vulnerable SSLv3 is off.
The only reason TLS_FALLBACK_SCSV is helpful against POODLE is if you need to support SSLv3 clients (really old IE versions or something). Those clients will still be vulnerable to the attack, but modern clients which support that option would be safe against the downgrade attack.
Upgrade to the latest OpenSSL package that implements TLS_FALLBACK_SCSV. Then in your Apache configuration disable SSLv3 as well.
SSLProtocol all -SSLv2 -SSLv3
This answer on the 'askubuntu' stack site goes into a lot more detail and has answers for how to configure a bunch of different servers for this.
https://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566
As far as I understand it, it's not a configuration in Apache but a behavior of openssl.
OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications
to block the ability for a MITM attacker to force a protocol
downgrade.
https://www.openssl.org/news/secadv_20141015.txt
On Debian, you can upgrade openssl without upgrading libssl, you really want libssl to be upgraded. Apache uses libssl.
I can confirm is not need change nothing on Apache (at least for Ubuntu 14.04) I have restarted Apache after the update of openssl and TLS_FALLBACK_SCSV is working.
Put the following line in your configuration file, or replace any existing line starting with SSLProtocol:
SSLProtocol All -SSLv2 -SSLv3
Then run: $ sudo apache2ctl configtest && sudo service apache2 restart
You can test running command $ openssl s_client -connect <host>:<port> -ssl3
TLS_EMPTY_RENEGOTIATION_INFO_SCSV is the magic-word.
For more details, refer to http://www.exploresecurity.com, this is what it says:
TLS_FALLBACK_SCSV is a fake cipher suite advertised in the Client
Hello, which starts the SSL/TLS handshake. SCSV stands for “Signaling
Cipher Suite Value”. The idea of using a cipher suite as a signal is
not new: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is a way clients can
advertise that they support secure renegotiation (addressing
CVE-2009-3555)
So, finally, for a Spring-boot project with embedded Apache Server, configuration would show up something like this:
server.ssl.enabled-protocols=TLSvx,TLSvx.y....
server.ssl.protocol=TLS
server.ssl.ciphers=TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_............TLS_EMPTY_RENAGOTIATION_INFO_SCSV
server.server-header="Willi Wonka!"
PS - To see all the the Spring-boot configurations / properties, plese visit this: https://docs.spring.io
I am running a secure site on apache and openssl 1.0.1.
This works fine in the browser, but when I curl the site, I am getting the following error
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)
From what I can find, this is some incompatibility between openssl 0.9.8 on the client, and 1.0.1 on the server.
Is there maybe some server-side configuration in mod_ssl to prevent this error, or would I be best to downgrade to 0.9.8, and if the latter, any advice for doing so on Ubuntu? For example, if I apt-get remove and apt-get install, do I need to reinstall / restart apache for the changes to take effect?
Thanks,
This is an old question, but since it is still unanswered:
This is a bug in OpenSSL 0.9.8, but can be fixed (or overridden) in Apache. See https://stackoverflow.com/a/8058839 for a fix. Note that the ServerName directive should be identical to the name used by the client (e.g., "localhost" will not work).