Re: Issue while configuring keystore/SSL for Tomcat 8.5.33
can you share the full debug log ? what is the client for this SSL service ? browser or some other standalone programs what version of JDK is being used? On Thu, Oct 18, 2018 at 2:20 PM Sashidharan Ramamurthy < sashidharan.ramamur...@ericsson.com> wrote: > Any updates users of tomcat on this issue!!! > > -Original Message- > From: Sashidharan Ramamurthy > Sent: Wednesday, October 17, 2018 4:22 PM > To: users@tomcat.apache.org > Subject: FW: Issue while configuring keystore/SSL for Tomcat 8.5.33 > > Hi Tomcat user group, > > We have installed and deployed Tomcat Version: 8.5.33 in our machine. > > Software: AIX > > We configured SSL at 8443 port using below command for creating keystore. > > $JAVA_HOME/bin/keytool -genkey -alias iscpkey -keystore > $outputfile -keyalg RSA -dname "CN=${site}, OU=Network Solutions, O=ISCP, > L=Piscataway, C=US" -storepass "changeit" -keypass "changeit" -validity > 1 > > Though 8443 port no has started, we are unable to connect from SSL client. > We are getting SSLException in our client. > > We enabled java.net.debug with SSL logs. > > Client Hello and Server Hello is done but fails soon afterwards in SSL > with internal_error. > > *** ServerHelloDone > https-jsse-nio-8443-exec-4, WRITE: TLSv1 Handshake, length = 1736 > https-jsse-nio-8443-exec-5, READ: TLSv1 Alert, length = 2 > https-jsse-nio-8443-exec-5, RECV TLSv1 ALERT: fatal, internal_error > https-jsse-nio-8443-exec-5, fatal: engine already closed. Rethrowing > javax.net.ssl.SSLException: Received fatal alert: internal_error > https-jsse-nio-8443-exec-5, fatal: engine already closed. Rethrowing > javax.net.ssl.SSLException: Received fatal alert: internal_error > https-jsse-nio-8443-exec-5, called closeOutbound() > https-jsse-nio-8443-exec-5, closeOutboundInternal() > https-jsse-nio-8443-exec-5, SEND TLSv1 ALERT: warning, description = > close_notify https-jsse-nio-8443-exec-5, WRITE: TLSv1 Alert, length = 2 > > We are unable to proceed further. > > Can you let me know what could be the reason? > > Also, if this is not the correct tomcat group, can you point me to correct > group? > > Thanks and Regards, > Sashi > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: How to implement Security Headers in Tomcat 6
If the technology is java/j2ee then you can implements some sort of servlet filter where you can manipulate the HTTP response to add these headers for each outgoing response. I believe other platforms like .Net should also support similar feature to customize the request and response objects. On Mon, May 29, 2017 at 12:28 PM, Shaik, Mohammad N. < mohammad.n.sh...@accenture.com> wrote: > Hello, > > Can someone please let me know if the following headers are compatible > with Tomcat 6.x version? If yes, then how do we enable them? > > Headers: > 1) Strict-Transport-Security > 2) Content-Security-Policy > 3) Public-Key-Pins > 4) X-Frame-Options > 5) X-XSS-Protection > 6) X-Content-Type-Options > 7) X-Robots-Tag > > > Kind Regards, > Mohammad Nayeem > > > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise confidential information. If you have > received it in error, please notify the sender immediately and delete the > original. Any other use of the e-mail by you is prohibited. Where allowed > by local law, electronic communications with Accenture and its affiliates, > including e-mail and instant messaging (including content), may be scanned > by our systems for the purposes of information security and assessment of > internal compliance with Accenture policy. > > __ > > www.accenture.com >
Re: tomcat does not choose the higher curve when EC ciphers are configured
thanks. I believe as a part of cipher negotiation the server (tomcat) should do this rather than the provider (JDK/SunJC) On Tue, Dec 20, 2016 at 8:49 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > manjesh, > > On 12/20/16 6:19 AM, manjesh wrote: > > Below shown snippet is the ciphersuite configuration. Tomcat > > version 8.026 and JDK 1.8 > > > > > > > protocol="org.apache.coyote.http11.Http11NioProtocol" > > maxThreads="150" scheme="https" secure="true" SSLEnabled="true" > > clientAuth="false" sslProtocol="TLSv1.2" EnabledProtocols="TLSv1.2" > > ke ystoreFile="work/keystore/keystore.jks" keystorePass="*" > > keyAlias="selfsigned.tomcat" keystoreType="JKS" > > ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA > > _WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_ > > SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_ > > AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_ > > RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256" > > useServerCipherSuitesOrder="true" server="APPSERVER" > > SSLDisableCompression="true" /> > > > > > > Tested with Nmap > > > > Check the server for the supported cipher suites. > > > > nmap -p 443 --script ssl-enum-ciphers.nse hostname > > > > The result shows server supports few ciphers with curves > > secp160k1,secp192k1, secp224k 1,secp256k1..etc > > > > configure Nmap to probe the server with only two curve sizes > > secp160k1,secp256k1 > > > > But this time server selects cipher supporting secp160k1 but > > not secp256k1 even though secp256k1 is mutually stronger one than > > secp160k1 > > > > How to enforce server to select the mutually existing higher curve > > size? > > I'm not sure Java allows you to select the specific curve you'd like > to use -- only the cipher suite, which doesn't specify a curve to use. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJYWUvxAAoJEBzwKT+lPKRYyQEP/R3crsrDwQ5PRXEG2lRHXagV > u06qEQnPmI4lYFVj6Fcb+tbzyN255xGN2Sw8QyNJkW7u7kYK2cRbsEWYcufu0ucY > U4Xmrk5tmyIaEbXUbB4rtFOCK9axXyXSCOHcPak3McuYpVx8gpXDG3H51t/5MxCg > xyVw6AGOZB5fWKWOL9uH5RHFya72FiK9hVp+XTbN/SEKgGR2qYPGGDRzS7z5kyAV > CBrXj/WuscZlouUAJ6YIaFDY1PSlWcf2f6E0WWKpgYxP8bqE0Bwo01c1PPr1Slko > uudSbryNARccrPkGPQ7rFwyFyCLe1ENSPjzoofwUYMFZFdBVd6QphGnNXrl2ywIb > qYNBsaTBu0/fwGa1H/5M4w8OapTfVBMpyu/a9XNV4NOXBa5Q1ggIfom2JGYU3zpU > ubazsTF69Wqr1WuwYwfu2e5Z58DdUTPWhBdHgWUlFFy652Kw7gJNPUnEAFntJikh > WWgkLW2P8SWvilEfb5htyzYhuSJnPGFRInNwx9gSuJ+7gEmY3Ka3Zg4nXQO2P/xq > cjkHntQSb3eB5xiEeiDfJk9Vxb3nIUIxHskeUYyuiHK/rKlVNiabYEy1anxeTx0K > x5YHNN2dq86Gy2g4r9BQiXgg598punUybVmAc5fR75vw+5f7vYXLltEOI/AO3Wop > zHWLPJnMZyYfEyjWdcBh > =PRwc > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
tomcat does not choose the higher curve when EC ciphers are configured
Below shown snippet is the ciphersuite configuration. Tomcat version 8.026 and JDK 1.8 Tested with Nmap Check the server for the supported cipher suites. nmap -p 443 --script ssl-enum-ciphers.nse hostname The result shows server supports few ciphers with curves secp160k1,secp192k1, secp224k 1,secp256k1..etc configure Nmap to probe the server with only two curve sizes secp160k1,secp256k1 But this time server selects cipher supporting secp160k1 but not secp256k1 even though secp256k1 is mutually stronger one than secp160k1 How to enforce server to select the mutually existing higher curve size?
Re: how to test hash collision security fix in tomcat 7.1
Hi, The exact version of tomcat I am working with is 7.0.27 I am verifying the fix discussed here http://news.softpedia.com/news/Apache-Tomcat-Workaround-for-Hashtable-Collision-DoS-Vulnerability-243544.shtml Here is the snippet of implementation [ org.apache.tomcat.util.http.Parameters.java] private int limit = -1; > this is being set to the value of maxParameterCount mentioned in Connector tag of server.xml private int parameterCount = 0; public void addParameter( String key, String value ) throws IllegalStateException { if( key==null ) { return; } parameterCount ++; if (limit > -1 && parameterCount > limit) { // Processing this parameter will push us over the limit. ISE is // what Request.parseParts() uses for requests that are too big parseFailed = true; throw new IllegalStateException(sm.getString( "parameters.maxCountFail", Integer.valueOf(limit))); } ArrayList values = paramHashValues.get(key); if (values == null) { values = new ArrayList(1); paramHashValues.put(key, values); } values.add(value); } now what happens when number of request parameters exceeds maxParameterCount ? -Manjesh On Thu, May 31, 2012 at 2:39 AM, Konstantin Kolinko wrote: > 2012/5/30 manjesh : >> Hi , >> I have downloaded tomcat 7.1 for Windows OS >> > > 1. There is no such version. I do not know what you are testing. > >> added the following parameter (maxParameterCoun) into server.xml >> >> > connectionTimeout="2" >> redirectPort="8443" maxParameterCount="5"/> >> >> >> >> restarted the server. >> >> to test this fix , I created a JSP with 6 text fields having same name >> ( example 6 input boxes ) >> when I give input for all of these input fields and click on submit, >> still the request is being processed... >> I am expecting the request processing should be aborted and >> illegateStateException must be thrown according to the fix done in >> Parameters class of (tomcat-coyote.jar) >> > > 2. Your expectations are wrong. Documentation for that option in > configuration reference says exactly what happens what you have more > parameters than specified by that option. > > An IllegalStateException cannot be thrown, because Servlet API does > not allow that. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -- Regards Manjesh - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
how to test hash collision security fix in tomcat 7.1
Hi , I have downloaded tomcat 7.1 for Windows OS added the following parameter (maxParameterCoun) into server.xml restarted the server. to test this fix , I created a JSP with 6 text fields having same name ( example 6 input boxes ) when I give input for all of these input fields and click on submit, still the request is being processed... I am expecting the request processing should be aborted and illegateStateException must be thrown according to the fix done in Parameters class of (tomcat-coyote.jar) am I doing test correctly..? please help me Note: I have also tried adding parameter to JAVA_OPTS in run.bat -- Regards Manjesh - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org