There is a javamail protocol property
mail.smtp.ssl.protocols
This allows the user to use a particular protocol (TLSv1.2 or 1.1).
What if the property is not used? Will it be then set by the JVM settings?
Also if I want to use TLSv1.3, what version of Javamail I would have to use?
Thanks
In javamail versions below 1.5.3 if the sysprop is not set it uses TLSv1.0, which (1) doesn't work at all on recent versions of Java and (2) won't work with increasingly many servers because 1.0 was sort of 'broken' briefly by BEAST and many authorities no longer permit it. See postfix and openJDK 11: "No appropriate protocol (protocol is disabled or cipher suites are inappropriate)" especially the section of my answer marked EDIT.
On more recent versions, as you can see in the source linked there, it uses the JVM defaults except it removes SSL versions if present -- and all versions of Java since 2015 have omitted SSLv3 from JVM defaults (because it is really broken by POODLE). (SSLv2Hello, which wasn't an actual protocol version anyway, was removed even earlier.)
To use TLSv1.3 you need a version of Java that supports it: 11 up or 8u261 up, or any non-absurd Java version with a recent enough version of BouncyCastle's BCTLS installed and configured instead of or at least before JSSE -- and of course a server that supports it. Javamail just passes this setting through to JSSE or BCTLS as a set of character strings, it doesn't need new code for different versions of TLS including 1.3.
Related
WSO2IS 5.8 include Log4j 1.2.17
A security vulnerability, CVE-2019-17571 has been identified against Log4j 1. Log4j includes a SocketServer that accepts serialized log events and deserializes them without verifying whether the objects are allowed or not. This can provide an attack vector that can be expoited.
Someone knows if this vulnerability can be exploited in the context of WSO2IS 5.8?
Thanks in advance!
WSO2 is very frequently issuing security patches as and when the issues are discovered. Can you please write to security#wso2.com and check.
Also - as a security best practice we recommend to use security#wso2.com all the time to report security issues - this is a common practice followed by all open source projects.
UPDATE: Even though the WSO2 Identity Server 5.8.0 has this dependency, it does not use any of the functionalities provided by SocketServer. So, anyone using 5.8.0 version is NOT affected. Also, since IS 5.9.0 this dependency is upgraded to Log4j 2.
More details here: https://wso2.com/security
Does anyone know if the Enterprise version of JBoss supports the concurrent utilities defined in JSR-236 and, if not, whether there is any roadmap for their support?
I couldn't find any info online and the only related RH knowledge base post is not accessible without a paid subscription.
JBoss EAP 7 does support the JSR-236 Concurrency Utilities. As far as I know this is the first release that supports them.
Is there away to make DB2 not accept SSL3?
I'm trying to secure couple of DB2 databases I have on couple of servers against the POODLE attack. I know you can do this through the Operating System itself, but my question is if I don't have control over the OS can I at least make DB2 stop using use SSL3?
I have many Java applications and some of it might be using SSL3, I want to be sure these application will fail when they try to use the SSL3 to connect these DB2 databases.
Starting with DB2 LUW 9.7 (I'm assuming you mean LUW here...), you can specify which implementation of SSL you want to use when doing the handshake. It looks like (at least since they implemented this configuration option) DB2 has only ever supported TLS. The configuration option is called ssl_version.
Additionally, you can specify which ciphers you wish to use with the ssl_cipherspecs configuration option. The default is to allow DB2 and the client to negotiate the strongest cipher they both understand.
Are there drawbacks to using the TokenAwarePolicy over the current default of RoundRobinPolicy?
It seems to me that routing requests to nodes identified as being replicas by the routing-key should always be preferable, and a RoundRobinPolicy wrapped by TokenAwarePolicy should be the default?
There is no real drawback to using TokenAwarePolicy and in fact we've changed the default in recent releases (2.0.2) so it is now using token aware.
What are the different Security modes available on Laravel 4 when using the Crypt::encrypt method. The Security documentation shows how to use the Crypt::setMode with ctr as the mode set. What are the other modes that can be used?
I did go through the source of the Encryption class and noticed that cbc is being set by default. Are there other modes that can be used?
According to the source code, it seems that you can use anything that PHP's mcrypt supports. There are two pretty extensive lists of Available Cyphers and
Available Modes.
Laravel 4.0.0 source code reference:
https://github.com/laravel/framework/blob/v4.0.0/src/Illuminate/Encryption/Encrypter.php#L79
https://github.com/laravel/framework/blob/v4.0.0/src/Illuminate/Encryption/Encrypter.php#L245-L259