[jira] [Commented] (GERONIMO-6793) Do not auto-enable all available Cyphers in TLS/SSL protocol handling in MailConnection
[ https://issues.apache.org/jira/browse/GERONIMO-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352668#comment-17352668 ] Fredrik Jonson commented on GERONIMO-6793: -- The current geronimo-javamail implementation _already_ aligns with and relies on the jvm defaults today, only it is currently using all the jvm's _supported_ ciphers instead of only its_enabled_ ciphers. So, surely geronimo-javamail _can continue to align_ with the jvm defaults, changing it only to use the set of _enabled_ jvm ciphers for tls sockets by default instead. That follows the principle of least surprise, and general knowledge of TLS configuration for the jvm. And if someone for some reason do not want to use the same default enabled ciphers for their smtp client in geronimo-javamail as for their other jvm TLS socket clients, they will be able override it with the "mail.smtp.ssl.ciphersuites" property when that is implemented. That would also be consistent with the proposed patch in GERONIMO-6792, which also uses the _jvm default protocols_ if nothing else is specified by javamail property mail.smtp.ssl.protocols. BTW, in OpenJDK the jvm http client has a specific flag "https.cipherSuites" which affects only http clients. So if you have specific needs for http, you do not have to modify the general "jdk.tls.client.cipherSuites" which applies to all client TLS sockets. > Do not auto-enable all available Cyphers in TLS/SSL protocol handling in > MailConnection > --- > > Key: GERONIMO-6793 > URL: https://issues.apache.org/jira/browse/GERONIMO-6793 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: mail >Reporter: Richard Zowalla >Priority: Major > > Check and discuss, if it is a good idea to enable all cyphers in TLS/SSL > protocol handling in MailConnection.java > Some cyphers are deprecated for good reasons and shouldn't be used. > This enhancement might possibily include > * Allow users to specifiy cyphers via properties (custom factory is already > possible) > * If we have no user defined cyphers available, fallback to the JVMs default > cyphers. > > This is a follow up issue raised from the discussion on the dev mailing list, > see > http://mail-archives.apache.org/mod_mbox/geronimo-dev/202012.mbox/%3C096fbb867eda8e090eddf80fbd81cf787ac87945.camel%40hs-heilbronn.de%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GERONIMO-6793) Do not auto-enable all available Cyphers in TLS/SSL protocol handling in MailConnection
[
https://issues.apache.org/jira/browse/GERONIMO-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352563#comment-17352563
]
Fredrik Jonson commented on GERONIMO-6793:
--
[~romain.manni-bucau] I'm curious, why would it be a bad idea to default to
aligning with the ciphers _enabled by default_ by the JVM? I.e
SSLSocket.getEnabledCipherSuites().
I would prefer if the implementation defaulted to the jvm's enabled ciphers. At
least as long as a explicit list of ciphers isn't provided via the
"mail.smtp.ssl.ciphersuites" property. Selecting by hand and hard coding a list
of ciphers in geronimo-javamail risk becoming a maintenance burden, and a
source of obscure runtime errors as seen in GERONIMO-6792.
BTW, looking at the code, AFAIU, the current implementation explicitly
overrides the jvm's default selection (getEnabledCipherSuites()) and instead
enables all supported cipher suites. This seems intentional, but I cannot find
any reason for it in svn version history or jira. Anyone know why? Are there
really jvms that does not provide a list of enabled ciphers at all by default?
https://svn.apache.org/viewvc?view=revision=1641706
https://svn.apache.org/viewvc/geronimo/javamail/tags/geronimo-javamail_1.6-1.0.0/geronimo-javamail_1.6_provider/src/main/java/org/apache/geronimo/javamail/util/MailConnection.java?view=markup#l595
Below is the output from comparing jvm cipher suits of Openjdk 1.7, 8 and 11,
comparing supported vs enabled ciphers. The notable difference is that that a
small number of known weak ciphers are not included in the list of enabled
ciphers. It seems a small and good first step is to move from using supported
to using enabled ciphers by default.
{{
= OpenJDK 11 =
Supported ciphers [TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Disabled ciphers []
= OpenJDK 1.8 =
Supported ciphers [TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
[jira] [Comment Edited] (GERONIMO-6792) Fix hard-coded TLSv1 version in MailConnection.java for Java Mail 1.6
[ https://issues.apache.org/jira/browse/GERONIMO-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352445#comment-17352445 ] Fredrik Jonson edited comment on GERONIMO-6792 at 5/27/21, 12:43 PM: - After RFC 8996 - Deprecating TLS 1.0 and TLS 1.1 - was published in march 2021, I have noticed that some mail providers indeed now disallow TSLv1.0. This obviously makes the current release of geronimo-javamail fail delivery to such RFC-compliant servers. I have locally built and manually tested the patch GERONIMO-6792-v4-no-hardcoding.diff. I can confirm that it by default selects the default TLS protocols of the JVM, which is a great default behaviour btw. I have also tested using the mail.smtp.ssl.protocols flag, with various protocol versions, and it appears to also work as intended. Is there anything else a non-committer can do to help nudge this into a proper (1.0.1?) release sometime soon? PS. A big _Thank you_ to Richard Z for finding the bug, and proposing a patch! was (Author: fredrikj): After RFC 8996 - Deprecating TLS 1.0 and TLS 1.1 - was published in march 2021, I have noticed that some mail providers indeed now disallow TSLv1.0. This obviously makes the current release of geronimo-javamail fail delivery to such RFC-compliant servers. I have locally built and manually tested the patch GERONIMO-6792-v4-no-hardcoding.diff. I can confirm that it by default selects the default TLS protocols of the JVM, which is a great default behaviour btw. I have also tested using the mail.smtp.ssl.protocols flag, with various protocol versions, and it appears to also work as intended. Is there anything else a non-committer can do to help nudge this into a proper (1.0.1?) release sometime soon? PS. A big _Thank you_ to Richard W for finding the bug, and proposing a patch! > Fix hard-coded TLSv1 version in MailConnection.java for Java Mail 1.6 > - > > Key: GERONIMO-6792 > URL: https://issues.apache.org/jira/browse/GERONIMO-6792 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: mail >Reporter: Richard Zowalla >Priority: Major > Attachments: GERONIMO-6792-v4-no-hardcoding.diff, > GERONIMO-6792-v4.diff > > > Hi, > I encountered some issues when using Geronimo Java Mail 1.6 (1.0.0) bundled > with TomEE 8.0.5. The related thread [1] can be found on the > [us...@tomee.apache.org|mailto:us...@tomee.apache.org] Mailing-List. > In short: > * Our mail server does only support TLS 1.2 or TLS 1.3 > * Geronimo Java Mail 1.6 in version 1.0.0 has TLS 1.0 hard-coded in the > source and does not use the default protocols or the specified ones via > *mail.smtp.ssl.protocols* for a TLS connection. > I have attached a patch created via SVN DIFF. > [1] [https://www.mail-archive.com/users@tomee.apache.org/msg17544.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GERONIMO-6792) Fix hard-coded TLSv1 version in MailConnection.java for Java Mail 1.6
[ https://issues.apache.org/jira/browse/GERONIMO-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352445#comment-17352445 ] Fredrik Jonson commented on GERONIMO-6792: -- After RFC 8996 - Deprecating TLS 1.0 and TLS 1.1 - was published in march 2021, I have noticed that some mail providers indeed now disallow TSLv1.0. This obviously makes the current release of geronimo-javamail fail delivery to such RFC-compliant servers. I have locally built and manually tested the patch GERONIMO-6792-v4-no-hardcoding.diff. I can confirm that it by default selects the default TLS protocols of the JVM, which is a great default behaviour btw. I have also tested using the mail.smtp.ssl.protocols flag, with various protocol versions, and it appears to also work as intended. Is there anything else a non-committer can do to help nudge this into a proper (1.0.1?) release sometime soon? PS. A big _Thank you_ to Richard W for finding the bug, and proposing a patch! > Fix hard-coded TLSv1 version in MailConnection.java for Java Mail 1.6 > - > > Key: GERONIMO-6792 > URL: https://issues.apache.org/jira/browse/GERONIMO-6792 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: mail >Reporter: Richard Zowalla >Priority: Major > Attachments: GERONIMO-6792-v4-no-hardcoding.diff, > GERONIMO-6792-v4.diff > > > Hi, > I encountered some issues when using Geronimo Java Mail 1.6 (1.0.0) bundled > with TomEE 8.0.5. The related thread [1] can be found on the > [us...@tomee.apache.org|mailto:us...@tomee.apache.org] Mailing-List. > In short: > * Our mail server does only support TLS 1.2 or TLS 1.3 > * Geronimo Java Mail 1.6 in version 1.0.0 has TLS 1.0 hard-coded in the > source and does not use the default protocols or the specified ones via > *mail.smtp.ssl.protocols* for a TLS connection. > I have attached a patch created via SVN DIFF. > [1] [https://www.mail-archive.com/users@tomee.apache.org/msg17544.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GERONIMO-5440) Dos line endings (^M) makes all unix shell scripts unexecutable
[ https://issues.apache.org/jira/browse/GERONIMO-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fredrik Jonson closed GERONIMO-5440. Resolution: Won't Fix Geronimo App Server is dormant, in the attic even? Not relevant anymore. > Dos line endings (^M) makes all unix shell scripts unexecutable > --- > > Key: GERONIMO-5440 > URL: https://issues.apache.org/jira/browse/GERONIMO-5440 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: commands >Affects Versions: 2.1.6 > Environment: Ubuntu 10.04 > Java(TM) SE Runtime Environment (build 1.6.0_20-b02) > Geronimo 2.1.6 jetty6 javaee5 2.1.6 >Reporter: Fredrik Jonson >Priority: Minor > > All shell scripts in geronimo 2.1.6 jetty6 version 2.1.6 seems to have been > encoded with dos line endings, which makes them unexecutable: > Download geronimo-jetty6-javaee5-2.1.6-bin.tar.gz > tar xvf geronimo-jetty6-javaee5-2.1.6-bin.tar.gz > cd geronimo-jetty6-javaee5-2.1.6 > bin/startup.sh > bash: bin/startup.sh: /bin/sh^M: bad interpreter: No such file or directory > The issue is easily fixable though, convert all dos line endings to unix line > endings: > perl -pi -e 's/\r\n/\n/g' bin/*.sh > PS. In geronimo's jira version 2.1.6 is not available in the "Affects > version/s" option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] Created: (GERONIMO-5440) Dos line endings (^M) makes all unix shell scripts unexecutable
Dos line endings (^M) makes all unix shell scripts unexecutable --- Key: GERONIMO-5440 URL: https://issues.apache.org/jira/browse/GERONIMO-5440 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: commands Affects Versions: 2.1 Environment: Ubuntu 10.04 Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Geronimo 2.1.6 jetty6 javaee5 2.1.6 Reporter: Fredrik Jonson Priority: Minor All shell scripts in geronimo 2.1.6 jetty6 version 2.1.6 seems to have been encoded with dos line endings, which makes them unexecutable: Download geronimo-jetty6-javaee5-2.1.6-bin.tar.gz tar xvf geronimo-jetty6-javaee5-2.1.6-bin.tar.gz cd geronimo-jetty6-javaee5-2.1.6 bin/startup.sh bash: bin/startup.sh: /bin/sh^M: bad interpreter: No such file or directory The issue is easily fixable though, convert all dos line endings to unix line endings: perl -pi -e 's/\r\n/\n/g' bin/*.sh PS. In geronimo's jira version 2.1.6 is not available in the Affects version/s option. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4573) OpenEJB tries to parse sun-ejb-jar.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fredrik Jonson resolved GERONIMO-4573. -- Resolution: Fixed Fix Version/s: 2.1.4 I can confirm that the solution in OPENEJB-1006 has resolved this issue too. When I replace the openejb-core snapshot jar with the latest release candidate in the repository of a geronimo 2.1.4-SNAPSHOT, and use the following environment setting: JAVA_OPTS=-Dopenejb.vendor.config=GERONIMO I no longer see the deployment failure caused by the existence of a sun-ejb-jar.xml in my ejb module. OpenEJB tries to parse sun-ejb-jar.xml -- Key: GERONIMO-4573 URL: https://issues.apache.org/jira/browse/GERONIMO-4573 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.1.3 Environment: Deiban 5.0, sun jdk1.6u12, geronimo-jetty6 2.1.3. Reporter: Fredrik Jonson Fix For: 2.1.4 I'm trying to create an application with a inbound rar connector implementation, and have the ear deploy properly on both Geronimo and Glassfish 2.1. To solve that I declare my resource adapter reference both in a openejb-jar.xml for the geronimo specific configuration and a sun-ejb-jar.xml for the glassfish specific configuration. This solution works on glassfish, it ignores openejb-jar.xml as intended. In geronimo, openejb seems to pick up and try to parse the sun-ejb-jar.xml even though the ejb module also contains both a ejb-jar.xml and openejb-jar.xml. Since sun-ejb-jar.xml is application server specific for Sun/Glassfish I expect Geronimo to stay away from it entirely. This issue has been raised before, but I could not find anything relevant in jira. Check the following mail note: http://marc.info/?l=geronimo-devm=118857105323864 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4573) OpenEJB tries to parse sun-ejb-jar.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fredrik Jonson closed GERONIMO-4573. OpenEJB tries to parse sun-ejb-jar.xml -- Key: GERONIMO-4573 URL: https://issues.apache.org/jira/browse/GERONIMO-4573 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.1.3 Environment: Deiban 5.0, sun jdk1.6u12, geronimo-jetty6 2.1.3. Reporter: Fredrik Jonson Fix For: 2.1.4 I'm trying to create an application with a inbound rar connector implementation, and have the ear deploy properly on both Geronimo and Glassfish 2.1. To solve that I declare my resource adapter reference both in a openejb-jar.xml for the geronimo specific configuration and a sun-ejb-jar.xml for the glassfish specific configuration. This solution works on glassfish, it ignores openejb-jar.xml as intended. In geronimo, openejb seems to pick up and try to parse the sun-ejb-jar.xml even though the ejb module also contains both a ejb-jar.xml and openejb-jar.xml. Since sun-ejb-jar.xml is application server specific for Sun/Glassfish I expect Geronimo to stay away from it entirely. This issue has been raised before, but I could not find anything relevant in jira. Check the following mail note: http://marc.info/?l=geronimo-devm=118857105323864 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4573) OpenEJB tries to parse sun-ejb-jar.xml
OpenEJB tries to parse sun-ejb-jar.xml -- Key: GERONIMO-4573 URL: https://issues.apache.org/jira/browse/GERONIMO-4573 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: OpenEJB Affects Versions: 2.1.3 Environment: Deiban 5.0, sun jdk1.6u12, geronimo-jetty6 2.1.3. Reporter: Fredrik Jonson I'm trying to create an application with a inbound rar connector implementation, and have the ear deploy properly on both Geronimo and Glassfish 2.1. To solve that I declare my resource adapter reference both in a openejb-jar.xml for the geronimo specific configuration and a sun-ejb-jar.xml for the glassfish specific configuration. This solution works on glassfish, it ignores openejb-jar.xml as intended. In geronimo, openejb seems to pick up and try to parse the sun-ejb-jar.xml even though the ejb module also contains both a ejb-jar.xml and openejb-jar.xml. Since sun-ejb-jar.xml is application server specific for Sun/Glassfish I expect Geronimo to stay away from it entirely. This issue has been raised before, but I could not find anything relevant in jira. Check the following mail note: http://marc.info/?l=geronimo-devm=118857105323864 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
