Adobe Media Server and TLS 1.2 - apache

I am on AMS 5.07, apache 2.2, and openssl 1.01L and I cannot get TLS 1.2 working. I can only use up to TLS 1.0. Any tricks to getting TLS 1.2 enabled? I'm worried about fully updating apache to 2.4 since it is supposedly configured especially for AMS.

You can't, unless you upgrade
This issue is fixed with Apache 2.4.3 http://httpd.apache.org/docs/2.4/mod/mod_ssl.html
- see SSLCompression Directive
It will only use TLS 1.2 if SSL compression is turned off, and you can't turn it off unless you upgrade.

Related

Disable TLS 1.3 for GRPC or system-wide in Ubuntu?

I'm trying to use a GRPC client which is TLS 1.3 enabled on my system (Ubuntu 20.04). I'd like to force it to connect over TLS 1.2: I don't see any options to control this, so I thought I'd try disabling TLS 1.3 system-wide.
How do I do this? I tried adding
MaxProtocol = TLSv1.2
to my /etc/ssl/openssl.cnf as this page seems to suggest*, but my GRPC traffic continues over TLS 1.3 (perhaps I'm not reloading the config or something?). I've heard mention of boringssl when it comes to GRPC as well, so perhaps that has something to do with things.
I added it as the second line, right after HOME = .: you can see the whole file here

How to enable tls vers. 1.2 in haproxy

I have haproxy doing ssl termination. I have disabled sslv3.
The ssl testers says that I only have tls 1.0 enabled. How can I enable tls version 1.2 in haproxy ?
Thanks
We can specify these informations in default:
ssl-default-server-options force-tlsv12
It will apply for all server commands in haproxy config
ssl-default-bind-options force-tlsv12
It will apply for all bind command in haproxy config.
Check version of openssl. TLS 1.2 is in version 1.0.x. Older (for example 0.9.8 in Debian Squeeze) supports only TLS 1.0.

Globally disabling protocols in OpenSSL

Is it possible to globally disable TLS 1.1 for an application that is indirectly using OpenSSL?
I would like to disable TLS 1.1 for a C application that makes soap HTTPS calls using gSOAP.
Disabling TLS 1.1 fixes a intermittent SSL connection problem I have been experiencing for the last few days (SSL routines:SSL3_GET_RECORD:wrong version number).
Currently TLS 1.1 is disabled by using a custom build of gSOAP but ideally I would like to disable the protocol using a config file or some code in my application.
Ubuntu 12.04.5 LTS
OpenSSL 1.0.1-4ubuntu5.20
gSOAP 2.8.4-2
Although there is a global OpenSSL config file it can not be used to restrict the default SSL version(s). And unfortunately there seems to be no API or configuration for the gSOAP library to restrict the SSL version. So you must probably live with your custom build version and hope that someday they provide an API to set the SSL version.
At a minimum you will need gSOAP 2.8.28. Use the SOAP_TLSv1_2 option with soap_ssl_client_context() and soap_ssl_server_context() to restrict the TLS protocol to TLSv1.2 only. TLS1.0/TLS1.1/SSLv3 are disabled. You can't combine the SSL/TLS protocol options, so only TLSv1.2 will be enabled with this option. This works with OpenSSL 1.0.1 or later and recent GNUTLS versions. Perhaps there will be new options in upcoming gSOAP releases to support subsets of protocols, which would be nice.

how to enable TLS_FALLBACK_SCSV on apache

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

Modifying the ssl version using openssl on wamp server

I am currently working on testing some vulnerabilities in TLS 1.0. I have created a website and hosted it on wamp server 2.4. I am using openssl to create self-signed certificates for SSL encryption ver. 1.01. But the current openssl version uses TLS 1.2 provide. I want to use TLS 1.0 rather to test some of the vulnerabilities such as BEAST attack present in TLS 1.0. I would like to know how can I modify the version so that the website now uses TLS 1.0 protocol instead.
Try reading this the manual:
Then in the \wamp\bin\apache\apachex.y.z\conf\extra\httpd-ssl.conf find this line
SSLProtocol all -SSLv2
Then change that line to only include the protocol you want to test so it is the only one that is used.