Re: ECDSA Private Keys
Am 09.01.2020 um 21:45 schrieb Christopher Schultz: > DSA is almost never used. Nearly 100% of keys in the world are > plain-RSA or EC. I know of no CA that uses DSA for signing. So pretty > much every cert you will come across will be EC-with-RSA or > RSA-with-RSA (that's keytype-with-signature-type). I guess this might change. Let's Encrypt is quite popular and plans to change to ECDSA for Root and Intermediate certificates Source: https://letsencrypt.org/upcoming-features/ - Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Possible release of next 8.5.x in 2020
He Michael, On Sun, 12 Jan 2020 at 20:55, Michael Osipov wrote: > Am 2020-01-12 um 19:26 schrieb M. Manna: > > Hey All, > > > > Just trying to get a timeline (or possible release time) for next 8.5.x. > > The latest release is 8.5.50 from December 2020. I am assuming there is > one > > imminent for January 2020? > > > > This is purely for individual interest as my dev cycle requires a tomcat > > upgrade 4 times a year. > > This might be wrong because you could miss important releases with > security fixes or else. We operate under strict SLAs and every tomcat upgrade requires a full regression cycle for our product due to the nature of integration. And we only have 4 such slots per year to do it. Also, not all CVEs are relevant to what/how we use tomcat. With regards to my enquiry, I’m simply trying to find out whether there would be a new release coming out this January 2020. > >
Re: Possible release of next 8.5.x in 2020
Am 2020-01-12 um 19:26 schrieb M. Manna: Hey All, Just trying to get a timeline (or possible release time) for next 8.5.x. The latest release is 8.5.50 from December 2020. I am assuming there is one imminent for January 2020? This is purely for individual interest as my dev cycle requires a tomcat upgrade 4 times a year. This might be wrong because you could miss important releases with security fixes or else. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Possible release of next 8.5.x in 2020
Hey All, Just trying to get a timeline (or possible release time) for next 8.5.x. The latest release is 8.5.50 from December 2020. I am assuming there is one imminent for January 2020? This is purely for individual interest as my dev cycle requires a tomcat upgrade 4 times a year. Regards, M. MAnna
Re: ECDSA Private Keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Peter, On 1/10/20 2:07 PM, logo wrote: > Chris and Mark, > > >> Am 09.01.2020 um 21:49 schrieb Christopher Schultz >> : >> > All, > > On 1/9/20 3:45 PM, Christopher Schultz wrote: Mark and Peter, On 1/9/20 3:36 PM, Mark Thomas wrote: > On 09/01/2020 20:22, logo wrote: >> Mark, >> >>> Am 09.01.2020 um 20:36 schrieb Mark Thomas >>> : >>> >>> On 02/01/2020 09:24, logo wrote: >>> >>> >>> The connector comes up correctly, is accessible through the browser but if I test the ssl setup, I get an error message that the key/cert may not be used for "Key agreement" See: testssl.sh :8443 Signature Algorithm ECDSA with SHA256 Server key size EC 256 bits Server key usage Digital Signature, Key Encipherment Certificate incorrectly used for key agreement Server extended key usageTLS Web Server Authentication, TLS Web Client Authentication >> >> The key usage error is caused by identifying ECDH_RSA >> ciphers on the connector… (most certainly an unexpected >> edge case, I’ve debugged it that far). That should not be >> the case - as it is an ECDSA Cert, right? > I don't think so. > I'm seeing ECHD/RSA ciphers in the output and I am not > getting that warning. > My reading of a couple of questions on stack exchange > suggests RSA vs DSA ciphers depends on how the CA signs the > cert. My test CA signs with RSA. > >> Root and Intermediate are RSA-signed. > >> Cert is: Signature Algorithm ECDSA with SHA256 Server key >> size EC 256 bits > > DSA is almost never used. Nearly 100% of keys in the world are plain-RSA or EC. I know of no CA that uses DSA for signing. So pretty much every cert you will come across will be EC-with-RSA or RSA-with-RSA (that's keytype-with-signature-type). > > Obviously, the above is a mixture of half-truths and irrelevant > information. I was thinking of RSA versus DSA keys, not ECDSA as a > signature algorithm in its own right. > >> Maybe I’m causing a lot of hassle by asking these questions. So >> far I was happy to get a cert with a key, drop it in the right >> spot and all worked well. If I stick to RSA that should stay like >> this. The choice of RSA versus ECDSA is really up to you. Modern TLS will use ECDH for key agreement regardless of the certificate. This is how you get your forward-secrecy and it's a Good Thing. RSA and ECDSA certs are only used for authentication (checking the identity and trust of the site). RSA requires more CPU time for an equivalent-strength ECSDA key, so the obvious choice is ECDSA, right? Well, maybe not. Evidently, RSA is more resistant to quantum attacks (which are officially theoretical ATM), so RSA with a big-old key is your best bet if you are wearing a nice, thick tin-foil hat. Frankly, since the authentication step is quite short compared to the bulk encryption (which usually uses AES or some similarly fast symmetric encryption algorithm), the choice comes down to user preference. There is no clear winner for RSA versus ECSDA for certificates. But all software should work with all available primitives. So if Tomcat can't handle this for some reason and you just happen to be the first person to hit it, let's get it fixed (with respect and thanks to markt's efforts). The last thing we need is a monoculture where everything is using ECDH for key agreement (which is, AIUI, mathematically correct), RSA for authentication, AES for encryption, and SHA256 for signing. IF everyone is using the same cipher suite, then it means (a) the Bad Guys have an obvious target and (b) any problem with the design or implementation of that cipher suite, TLS, or e.g. OpenSSL means that the whole world is suddenly vulnerable. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4bTf4ACgkQHPApP6U8 pFj3/A//QndJMeUl7fJLo/61IFaSLpHTvMEwRVPLBLGSNpAF+P4U8/gpWsHJtDGD T2PuVyKLLy/Skb69sgFzb1r+Un2+7pTTPp2M+hPEVH09wBVis2RDRefUJH/b5Eyp /gUp7f7o01UjHw484/ocTzRedlv5ZoHN+9V+7dNBXOuvucwu1YWnyO6gd9oHAZkj //Hopus4R/oS47wGY64fiwD2Xqr8FkxLx7c1zfWCiGETQF+Q2AYslccZE+5jevSs EZiqwmgHYbzJqikJxpqg80pX4lcXwZxUllvvpMCxvPndlB36Azy5p0DXsni42uet hjDpJEtQYsdABP5ODGivQEv/rucq7phaehNuobPJUtmIKiAmapDj8T2BSld1f0CB S85rSbSJGM5/hnv92t0sz3ZMZHKdJyiu73E2YMd31kBJtV94cV71sOcpCByN698c d59RTYVbqP7VsXP/1TYR4EaqIqyruPa3u1v6zx23/DlafWFCmvoxUiBXiozYZ/4F ePFJ2PiUXAyhy/WA3xTD95FbRqs+ip9W0P7VNiuPHLbSrumPpawy/AOXtYWxbsp9 PQdwdbu7oK8SuPCLSj4S/oFn6P+jZ1TJ+rZXZhuc+pjAprZVSI5J7VkupNmPDVNb STEjG/LwasiaJPkO8/AC6n3EVhMye8ZsXX2XIzhBs0m1TpGCumI= =18Im -END PGP SIGNATURE- - To unsubscribe,
Re: Tomcat app within docker container
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Peter, On 1/10/20 8:06 AM, logo wrote: > Alex, > > Am 2020-01-10 12:47, schrieb Alex K: >> Just to follow-up on this in case it will be useful to anyone, I >> managed to use also the official tomcat image. I had to amend my >> .war files and use the openjdk:8-jdk version instead of >> openjdk:11-jdk. >> >> I have used the following Docker files to prepare my custom >> tomcat image (so as to have tomcat home at /opt/tomcat) and then >> deployed the final app as following: >> >> Got openjdk:8-jdk Docker file from: >> https://github.com/docker-library/tomcat/blob/807a2b4f219d70f5ba6f477 3d4ee4ee155850b0d/8.5/jdk8/openjdk/Dockerfile >> >> >> Amended the tomcat home to /opt/tomcat. >> >> Then deployed the app using the following Docker file: >> >> FROM tomcat:custom USER root ENV CATALINA_HOME /opt/tomcat ENV >> PATH $CATALINA_HOME/bin:$PATH RUN mkdir -p "$CATALINA_HOME" >> WORKDIR $CATALINA_HOME ADD iforms_files/app.war >> $CATALINA_HOME/webapps/ ADD iforms_files/orbeon.war >> $CATALINA_HOME/webapps/ ADD iforms_files/server.xml >> $CATALINA_HOME/conf/ ADD >> iforms_files/mariadb-java-client-2.4.1.jar $CATALINA_HOME/lib ADD >> iforms_files/setenv.sh $CATALINA_HOME/bin/ EXPOSE 8443 CMD >> ["catalina.sh", "run"] >> >> I also tried the alpine versions: >> https://hub.docker.com/layers/openjdk/library/openjdk/8-jre-alpine3.9 /images/sha256-ea81da311d33e052eeea34336018434bdc50596100f9c623193867faa 291b284 >> >> >> >> by using the same Dockerfile (by pointing to the custom built image FROM >> tomcat:alpine) I was able to deploy same app successfully >> reaching image size 281MB instead of 660MB with the default >> tomcat image. >> >> > Almost perfect. > > Now have a look at > https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HO ME_and_CATALINA_BASE. > > > > This way you don't have to change the installation directory. > > set CATALINA_BASE to /opt/tomcat and deploy all your conf and > webapp to the directories underneath /opt/tomcat. > > like this: > > FROM tomcat:8-jdk8-openjdk-slim #(slim saves you space) > > ENV CATALINA_BASE /opt/tomcat WORKDIR $CATALINA_BASE RUN mkdir -p > temp logs work webapps conf ADD iforms_files/app.war > $CATALINA_BASE/webapps/ ADD iforms_files/orbeon.war > $CATALINA_BASE/webapps/ ADD iforms_files/server.xml > $CATALINA_BASE/conf/ # you do need those: ADD > iforms_files/tomcat-users.xml $CATALINA_BASE/conf/ ADD > iforms_files/web.xml $CATALINA_BASE/conf/ > > ADD iforms_files/mariadb-java-client-2.4.1.jar $CATALINA_BASE/lib > ADD iforms_files/setenv.sh $CATALINA_BASE/bin/ > > EXPOSE 8443 CMD ["catalina.sh", "run"] > > optionally I'd recommend to change the user to tomcat (root is > baaah) +1 many times Remember, root in Docker is also root outside docker. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4bTBsACgkQHPApP6U8 pFgtpxAAnie14dTJg+v/DEmFnPRKRietvBhTRqxduMVAUXr11L0G/m8Ibh5irwR8 ZhTkuiieWdtCz/+dQLMzQIHk/QIbQTK1xTXTrjKgZxCGG87/lmEft2hR3CU2IC5O CZg1oyeGMpwJqYNOMszTbMeJcyU02qHpmf6iD8W3iPZVlDzkR3vjbA98V/+Q4KhZ 0Mv7uhE22/2Mq17CLFNo15zneP3oAg2UbGf8AzO3RM0ZGLKtGmBSUVz5nVvGxnp7 BS1VMXws66oy9LsLGvf5uf68VbYmh9VUIvODnb0HjKKxZBoWTfOwt/DKLj9QpUWr 2ucSrlt5iyjuT6zQPqDMH0V5GVtM2eXrlOSx6L2BYslgH6bG7eFRO7hU69RIlkLh aQMjUSEBAd6QKS+6QdbD+9gU9ZAew7OMhW3oJv5Ym89YIFzSonwKdav9780QCEry Pw5g4+gJBK/V+7tdjz0HVAO3NRpDOcxKAtpjFoJmtOWYf136jbwboyGMT1IOnksp oZMAsnrv7sU1Ig28ETmGyBudzZWpWImY8CsXZVVozU9XjIh0ivsLhS0A9vmQ5SUs Z+pwoQ/+tX0NQPh4gJCdX1hwt4CeCdNQ88fEvBgfho0p4LvvcdtBJcUlRGhy7xaq IgB0C4kxE0PAjq864oKt+3deqcHVZYzByBUUNnHAtiAUhx28N/E= =m7RV -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
