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?
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 Connector port=8080 protocol=HTTP/1.1 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 input type=text name=username/ 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
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)));
}
ArrayListString values = paramHashValues.get(key);
if (values == null) {
values = new ArrayListString(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
knst.koli...@gmail.com wrote:
2012/5/30 manjesh manjes...@gmail.com:
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
Connector port=8080 protocol=HTTP/1.1
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 input type=text name=username/ 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
