Re: BREAKTHROUGH (but not solved) Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

[James H. H. Lampert]

On 10/9/17, 2:19 PM, Christopher Schultz (Tomcat List guru) wrote (with 
regard to a "ciphers" clause in a connector tag):

. . .

You need to list everything.

. . .

Ok. I really didn't need a command-line tool (thanks, though, on behalf 
of whoever actually does end up needing one); just an example, and I 
found one at https://tinyurl.com/y9aqpkvm


Based on that example, I then pulled up the "Configured ciphers per 
connector" page on the TC 8.5 server, and copied and pasted all of them 
into a new ciphers clause on my connector tag, and then copied and 
pasted TLS_RSA_WITH_AES_256_CBC_SHA in at the end, from a copy of the 
SSLInfo output. After restarting Tomcat, "TLS_RSA_WITH_AES_256_CBC_SHA" 
appeared in the "Configured ciphers" page, and the AS/400 was able to 
access the server.


Thanks, Messrs. Schultz, Kreuser, Thomas of the Tomcat List, and Messrs 
Stone and Klement of the HTTPAPI List.


--
JHHL


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ISAPI and IIS 10 Logging Issue

[jumiller]

I'm having this very same issue with one slight difference.  I have six
Windows 2016 servers and logging works correctly on two of them.  I've gone
through nearly everything I can think of to determine what is different
about the two boxes that work and have hit a wall.  I have even done a full
compare of the Windows directory to no avail. The two boxes that do work
have two additional Windows Updates which I can't get to apply to the four
boxes that don't work: KB4013418 and KB3211320.  When I try to install those
updates on the boxes that don't work, I get "Update not applicable", likely
because those updates are superseded by KB4035631, which is also installed
on all six boxes.



--
Sent from: http://tomcat.10.x6.nabble.com/Tomcat-User-f1968778.html

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat SSL issue

[John Ellis]

John Ellis

405.285.2500 office


    

http://biz-e.io


-Original Message-
From: Terence M. Bandoian [mailto:tere...@tmbsw.com] 
Sent: Monday, October 9, 2017 4:49 PM
To: Tomcat Users List 
Subject: Re: Tomcat SSL issue

On 10/9/2017 10:01 AM, John Ellis wrote:
>
> I posted questions about this a couple of weeks ago I think it was. I 
> have been trying to get Tomcat running on a secure port with a valid 
> SSL certificate. We finally got version 9.0.0.M20 setup successfully 
> on port 9443 and I can go to that IP:port and get a Tomcat webpage but 
> when I go through all the steps using the keytool commands to submit a 
> certificate (we use Cacert.org) and try to plug that certificate into 
> the mix it doesn’t work. I still get an error message telling me that 
> I will have to create an exception to go to that IP address and port.
> Last Friday I even deleted the certificate and all the keystore file, 
> etc. and got the same exact error. So it appears that Tomcat is not 
> seeing the certificate at all since I get the same error about having 
> to add an exception whether or not I have a valid certificate in place 
> on the server.
>
> The lines we added to the server.xml file to get the secure port 
> working are-
>
> 
> maxThreads="150" scheme="https" secure="true"
>
> clientAuth="false" sslProtocol="TLS"
>
>
keystoreFile="/home/tomcat9.0.0.M20/apache-tomcat-9.0.0.M20/conf/keystore.jk
s"
>
>keystorePass="changeit" />
>
> John Ellis
>
>Terence I have tried putting my name in where it asks for the "first and
last name" part of filling out the certificate info but when I do that the
Cacert.org website says I have to authenticate the actual internal IP
address of this server and there is no way to do that that I know of.
Thanks, 

Hi, John-

Is it a browser that's displaying the error message and requesting that you
create an exception to continue?  If so, have you looked at the additional
information to determine what problems the browser has detected with the
certificate?

-Terence Bandoian
  http://www.tmbsw.com/


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enforcing server preference for cipher suites

[Konstantin Kolinko]

2017-10-09 19:31 GMT+03:00 Harish Krishnan :
> Hi All,
>
>  Need your expert input here.
> Not sure what I am doing wrong,  but I cannot get this server preference 
> cipher suites feature working.
>
> My setup:
> Latest tomcat 7.x build (which supports useServerCipherSuitesOrder attribute)
> Latest Java 1.8 build.
>
> No matter what value I set to this attribute (true OR false OR undefined 
> which is by default), I always see the Clients preference picked.
> As an example, if clients order is ABCDEF, and servers order is DEFABC, no 
> matter what value I set to this useServerCipherSuitesOrder attribute, always 
> the order selected is ABC...

It should work when running on Java 8.

Maybe try debugging
e.g. with breakpoint in org.apache.tomcat.util.compat.Jre8Compat
setUseServerCipherSuitesOrder()

https://wiki.apache.org/tomcat/FAQ/Developing#Debugging

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Enforcing server preference for cipher suites

[Harish Krishnan]

Thanks for the response, Peter.
The client is not doing anything other than a simple https connection to 
tomcat. The cipher sites used by the client is the default JRE 1.8 cipher 
suites.
I have not configured or requesting for any particular cipher suite when 
connecting to Tomcat. During the handshake, a particular cipher is 
automatically selected after the client server negotiation. 
The question I have is, the cipher that is automatically selected, is in the 
client preference order and not tomcat order as per the attribute 
useServerCipherSuitesOrder setting. 
Are we on same page?

Sent from my iPhone

> On Oct 9, 2017, at 11:51 PM, Peter Kreuser  wrote:
> 
> Harish,
> 
> 
>> Am 10.10.2017 um 00:00 schrieb Harish Krishnan :
>> 
>> Thanks for the response, Chris.
>> 
>> Below are my answers in order.
>> To keep the response as short as possible, i have not included the ciphers
>> list in the connector -
>> 
>> a) Tomcat 7.0.79 (will be updating to 7.0.82)
>> b) JRE 1.80_144
>> c) Our connector configuration is below.
>> d) We are using NIO.
>> e) I am using a simple java client that makes TLS connection to our tomcat
>> on below port. I am capturing the SSL handshake.
>> The way i tested the client preference is: Lets take the same example i
>> gave in my first email i.e. clients preference is ABCDEF and the tomcat
>> servers preference is DEFABC with *useServerCipherSuitesOrder* set to true.
>> During the 1st handshake connection, "A" cipher suite was chosen. I removed
>> "A" from my tomcat connector, restarted the service, and did the connection
>> test again.
>> "B" was chosen during this 2nd handshake. Same test was continued and
>> observed that CDEF were chosen next in order.
>> I am expecting DEFABC as the order of preference as per the
>> *useServerCipherSuitesOrder* setting.
> I believe that there is a misunderstanding. Your simple client does not seem 
> to handle the situation correctly (even not at all).
> I think if you request cipher B you will get B.
> 
> Please check with a ssl-tool like sslyze or testssl.sh. If your site is 
> available on the internet, you could try ssllabs.com.
> 
> The settings seem to be OK, unless I do not see an incorrect formatting on my 
> phone.
> 
> HTH,
> 
> Peter
> 
>> Let me know if i am missing anything or is my understanding is incorrect.
>> 
>> >   id="orion.server.https"
>>   acceptCount="100"
>>   *useServerCipherSuitesOrder*="true"
>>   ciphers="we have around 20 cipher suites listed..."
>>   clientAuth="want"
>> 
>> compressableMimeType="text/html,text/xml,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json"
>>   compression="on"
>>   compressionMinSize="2048"
>>   disableUploadTimeout="true"
>>   enableLookups="false"
>>   keystoreFile="keystore/xyz"
>>   keystorePass=""
>>   maxConnections="500"
>>   maxHttpHeaderSize="8192"
>>   maxKeepAliveRequests="500"
>>   maxThreads="250"
>>   minSpareThreads="25"
>>   noCompressionUserAgents="gozilla, traviata"
>>   port="8443"
>>   processorCache="500"
>>   protocol="org.apache.coyote.http11.Http11NioProtocol"
>>   scheme="https"
>>   secure="true"
>>   server="Undefined"
>>   sessionCacheSize="400"
>>   SSLEnabled="true"
>>   sslProtocol="TLS"
>>   sslEnabledProtocols="TLSv1.1, TLSv1.2"
>>   truststoreFile="keystore/xyz"
>>   truststorePass=""
>>   truststoreType="jks"
>>   URIEncoding="UTF-8" />
>> 
>> 
>> On Mon, Oct 9, 2017 at 2:06 PM, Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> 
>>> Harish,
>>> 
 On 10/9/17 12:31 PM, Harish Krishnan wrote:
 Need your expert input here. Not sure what I am doing wrong,  but I
 cannot get this server preference cipher suites feature working.
 
 My setup: Latest tomcat 7.x build (which supports
 useServerCipherSuitesOrder attribute) Latest Java 1.8 build.
 
 No matter what value I set to this attribute (true OR false OR
 undefined which is by default), I always see the Clients preference
 picked. As an example, if clients order is ABCDEF, and servers
 order is DEFABC, no matter what value I set to this
 useServerCipherSuitesOrder attribute, always the order selected is
 ABC...
>>> 
>>> What exact version of Tomcat are you using?
>>> What exact version of Java are you using?
>>> 
>>> Please post your  configuration, minus any secrets.
>>> 
>>> Do you know if you are using the BIO, NIO, or APR connector?
>>> 
>>> How are you determining client-preference?
>>> 
>>> - -chris
>>> -BEGIN 

FW: [error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection

[Gali, Vamsi A]

Hello,

Any help is appreciated on this issue.

Thank you,
Vamsi Gali


-Original Message-
From: Gali, Vamsi A 
Sent: Thursday, October 05, 2017 12:03 PM
To: 'Tomcat Users List'
Subject: RE: [error] SSL0266E: Handshake Failed, Could not establish SSL proxy 
connection

Hello,
I just realized that I didn’t provide the environment info & following are the 
details:

Tomcat:  apache-tomcat-7.0.75
IHS: HIS v8.5.5.x
OS: RHEL

We have IHS→mod_proxy(on IHS) → Tomcat.
I know that IHS isn’t the suggested webserver to use with Tomcat but it’s in 
use.
[error] SSL0266E: Handshake Failed, Could not establish SSL proxy connection 

When Tomcat is accessed through webserver url, it throws ‘500’ with the 
following stack on the IHS Error log:

[Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2313): proxy: HTTPS: fam 2 
socket created to connect to TOMCAT2 [Thu Oct 00 09:20:20 2017] [debug] 
proxy_util.c(2419): proxy: HTTPS: connection complete to  TOMCAT-IP:PORT 
(TOMCAT2) [Thu Oct 00 09:20:20 2017] [error] SSL0266E: Handshake Failed, Could 
not establish SSL proxy connection.
[Thu Oct 00 09:20:20 2017] [info] [client TOMCAT-IP] [7fa404014a60] [13789] 
SSL0240I: SSL Handshake Failed, Socket has been closed. Client sent fatal alert 
[level 2 (fatal), description 40 (handshake_failure)]  [TOMCAT-IP:PORT -> 
IHS:PORT] [09:20:20.000967434] 0ms [Thu Oct 00 09:20:20 2017] [debug] [client  
TOMCAT-IP] [7fa404014a60] Handshake transcript:
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]   [Thu Oct 
00 09:20:20 2017] [debug] [client  TOMCAT-IP]  client_version
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]gsksslDissector_8Bits
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]03
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]gsksslDissector_8Bits
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]03
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  TLSV12 [Thu Oct 00 
09:20:20 2017] [debug] [client  TOMCAT-IP]  random
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]gsksslDissector_32Bits
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]9xx
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]gsksslDissector_Opaque
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]Length: 28
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]1x 62 xx B3 1F 44 xx 
8E D2 xx x7 17 xx 59 x9 x9 .b...D...)...Y..
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]x1 91 19 08 25 xx DC 
xx E1 xx 20 xx %..o.9 x
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  session_id [Thu Oct 00 
09:20:20 2017] [debug] [client  TOMCAT-IP]  Length: 00 [Thu Oct 00 09:20:20 
2017] [debug] [client  TOMCAT-IP]  cipher_suites [Thu Oct 00 09:20:20 2017] 
[debug] [client  TOMCAT-IP]  Length: 14
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  0x Fx x6 00 00 xx 00 xx 
00 xx 00 xx 00 xx   ..V/.5
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  
tls_ri_scsv,tls_fallback_scsv,tls_rsa_with_rc4_128_sha,tls_rsa_with_aes_128_cbc_sha,tls_rsa_with_aes_256_cbc_sha,tls_rsa_with_3des_ede_cbc_sha,tls_rsa_with_rc4_128_md5
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  compression_methods 
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  Length: 01
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  00  
.
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]  Extensions [Thu Oct 00 
09:20:20 2017] [debug] [client  TOMCAT-IP]  Length: 00
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP]   Extension Count: 0
[Thu Oct 00 09:20:20 2017] [debug] [client  TOMCAT-IP] end handshake transcript 
[Thu Oct 00 09:20:20 2017] [debug] proxy_util.c(2442): proxy: HTTPS: 
pre_connection setup failed (500) [Thu Oct 00 09:20:20 2017] [debug] 
proxy_util.c(2022): proxy: HTTPS: has released connection for TOMCAT2
--
What’s done: IHS & Tomcat keystores contain required signers for proper 
communication. During the troubleshooting, I even added IHS server cert as a 
signer into Tomcat keystore and vice-versa but cannot get rid of this error.
Also, tried restricting both IHS & Tomcat to use TLSv1 but no success. 

Has anyone ran into similar issues? Or ever tried Tomcat with IHS using 
mod_proxy module?


Thank you,
Vamsi Gali


This communication may contain privileged and/or confidential information. It 
is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. This communication may contain nonpublic 
personal information about consumers subject to 

RE: Tomcat SSL issue

[John Ellis]

John Ellis

405.285.2500 office


    

http://biz-e.io


-Original Message-
From: Terence M. Bandoian [mailto:tere...@tmbsw.com] 
Sent: Monday, October 9, 2017 4:49 PM
To: Tomcat Users List 
Subject: Re: Tomcat SSL issue

On 10/9/2017 10:01 AM, John Ellis wrote:
>
> I posted questions about this a couple of weeks ago I think it was. I 
> have been trying to get Tomcat running on a secure port with a valid 
> SSL certificate. We finally got version 9.0.0.M20 setup successfully 
> on port 9443 and I can go to that IP:port and get a Tomcat webpage but 
> when I go through all the steps using the keytool commands to submit a 
> certificate (we use Cacert.org) and try to plug that certificate into 
> the mix it doesn’t work. I still get an error message telling me that 
> I will have to create an exception to go to that IP address and port.
> Last Friday I even deleted the certificate and all the keystore file, 
> etc. and got the same exact error. So it appears that Tomcat is not 
> seeing the certificate at all since I get the same error about having 
> to add an exception whether or not I have a valid certificate in place 
> on the server.
>
> The lines we added to the server.xml file to get the secure port 
> working are-
>
> 
> maxThreads="150" scheme="https" secure="true"
>
> clientAuth="false" sslProtocol="TLS"
>
>
keystoreFile="/home/tomcat9.0.0.M20/apache-tomcat-9.0.0.M20/conf/keystore.jk
s"
>
>keystorePass="changeit" />
>
> John Ellis
>
>Thanks for the reply Terence. Yes I get the message about needing to create
a security exception when I first try to open the Tomcat webpage on the
secure port of 9443. I have deleted the certificate and supporting files off
of the server as I was going to start over with a new certificate. I believe
the error said something about not being able to verify the certificate. I
think the main issue is that this is just an internal server here in our
office running RHEL 6. It is not setup as a web server and it just has the
name of "cowboy" (given that name by my boss) so it is hard to figure out
what to call the "First and last name" part when I am creating the CSR to
send to Cacert.org. I can't just use the name "cowboy" as I don't have any
way to validate that. Have you ever run into situations like this? As I said
before I am not a programmer or developer or anything like that. My
background was in computer hardware for over 25 years until I took this
position after being laid off from what was formerly WebMD. We installed
systems in dr's offices, etc. Any light you could shed on this would be
great!
Thanks 

Hi, John-

Is it a browser that's displaying the error message and requesting that you
create an exception to continue?  If so, have you looked at the additional
information to determine what problems the browser has detected with the
certificate?

-Terence Bandoian
  http://www.tmbsw.com/


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: ISAPI and IIS 10 Logging Issue

[Thomas, Michael]

-
On 06/10/17 22:42, Mark Thomas wrote:
> On 06/10/17 16:27, Mark Thomas wrote:
>>> On 10.05.2017 8:54, Thomas, Michael wrote:
>>>
>>> Unfortunately I am not getting much traction with Microsoft.  From the IIS 
>>> forum, it looks like they are pointing the finger in the direction of the 
>>> "third-party" that is writing the module.
>>
>> That is consistent with my experience with MS support.

Looks like you'll need to go back to MS support.

> I'll look at the IIS API docs next week and see if there is something
> different we should be doing in IIS 10 compared to 8.5 and earlier.

I can't find anything in the IIS API docs that indicates that this has changed 
in IIS 10 / Windows Server 2016.

I've added some debug logging and I see the following:

HttpFilterProc gets called with SF_NOTIFY_LOG

The JK code sees the original path [/jakarta/isapi_redirect.dll] and replaces 
it with the correct one - [/examples/] in my case.

The JK code sees the original [] query string and replaces it with the correct 
one - [foo=bar] in my case.

Given that this works as expected in Windows Server 2012 with exactly the same 
code AND that no API changes (that I can find) are documented for IIS 10 AND 
that debug logging shows that the expected calls are taking place AND the IIS 
log is not updated, all the evidence we have at the moment points squarely to 
an IIS 10 bug (or possibly an undocumented IIS 10 API).

Sorry it wasn't better news.

Mark
-
Thanks for looking into this!  I am SO glad that I am not the only one with 
this issue!

I am not really sure how to open up a support case with Microsoft.  I will give 
it a shot though and see how it goes.

-Mike



The preceding message (including attachments) is covered by the Electronic 
Communication Privacy Act, 18 U.S.C. sections 2510-2512, is intended only for 
the person or entity to which it is addressed, and may contain information that 
is confidential, protected by attorney-client or other privilege, or otherwise 
protected from disclosure by law. If you are not the intended recipient, you 
are hereby notified that any retention, dissemination, distribution, or copying 
of this communication is strictly prohibited. Please reply to the sender that 
you have received the message in error and destroy the original message and all 
copies.

request for beginner's documentation on start troubleshooting

[Riccardo Cohen]

Hello

I 'm quite new to tomcat and just spent one whole day because tomcat 
8.5.23 was freezing at startup for about 15 minutes !!! on a virtual 
private server on debian (while it used to work perfectly last week).


1) it was really difficult to know where was the problem because after 
15 minutes the application worked perfectly, and there was no particular 
error in the log


2) it was difficult to change the log level, the page 
http://tomcat.apache.org/tomcat-8.5-doc/setup.html does not mention how 
to change the logging level. The page 
http://tomcat.apache.org/tomcat-8.5-doc/logging.html seems too complex 
and written for advanced users


3) after setting log FINE I found that Creation of SecureRandom instance 
for session ID generation using [SHA1PRNG] took [580,051] milliseconds. 
Documentation for this problem is far far away in 
https://wiki.apache.org/tomcat/HowTo/FasterStartUp, and this page does 
not tell where to put the Java Option for tomcat


So my suggestions are:

- create a beginer's documentation separate from full feature 
documentation, which is too difficult to read for beginners


- explain some important settings, but not everything, only important 
things like port 8080 in conf/server.xml, environment variables etc.


- explicitely advise people to change 
CATALINA_OPTS=-Djava.security.egd=file:/dev/urandom to avoid starting 
hard problems on linux


- explain how to build a very simple jsp application, what is the 
meaning of WEB-INF , META-INF and what to put inside


- explain how deployement works in simple configuration where there is 
one application only.


- add a download sample app that works everywhere with one JSP and one 
Servlet for instance.



thanks.


--
Riccardo Cohen
+33 6 09 83 64 49
E5Group
http://www.5flow.com


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: BREAKTHROUGH (but not solved) Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

[Peter Kreuser]

Christopher,




Peter Kreuser
> Am 10.10.2017 um 00:14 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> James,
> 
>> On 10/9/17 5:19 PM, Christopher Schultz wrote:
>>> On 10/6/17 6:34 PM, James H. H. Lampert wrote:
>>> Noting that my connector tag is written using Tomcat 7 connector 
>>> syntax, is there a good example of how to code a ciphers clause
>>> for that tag?
>> 
>> Tomcat 8.5+ and 9.0+ can do it... but nobody has written a 
>> command-line tool around that capability. (I could have sworn such
>> a tool existed already. I guess I'll write one.)
> 
> Okay, it's in Tomcat 9, now. Grab Tomcat 9 trunk, build it ("ant
> deploy"), then run:
> 
> $ output/build/bin/ciphers.sh [cipherspec]
> 
> where "cipherspec" is an OpenSSL-style cipher suite spec, like:
> 
> $ output/build/bin/ciphers.sh 'DEFAULT'
> 
> This gives you the JVM's current default, and dumps-out all of the
> IANA-style cipher suite names. So if you want to add one cipher suite
> to the default Java suites, just do this:
> 
> $ output/build/bin/ciphers.sh 'DEFAULT'
> 
> and then add this to the end:
> 
> TLS_RSA_WITH_AES_256_CBC_SHA
> 
> (Unless TLS_RSA_WITH_AES_256_CBC_SHA is already present in the list.)
> 
> Note that the "DEFAULT" list has a bunch of junk you don't need.
> Specifically, you can probably get rid of all of these things with no
> ill effects, and your configuration will "look" simpler:
> 
> $ ./bin/ciphers.sh '!PSK:!aNULL:!DSA:!SRP:!DSS:HIGH'

A good read on the appropriate (openssl) cipher string that I use can be found 
here:
https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
Hynek explains the whys and don'ts and updates the string on a regular basis!

HTH

Peter

> Hope that helps,
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb9NkdHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFisoA//bj9GFzlMaZdPYXHt
> y2iQIToESUg6Wa8vU5lQscLDfqtXeAIawiXusILz/th1fCu1usy8HeC/5nBINXAQ
> McbEUSRiq6YitPXDIwXqbOGZS76vxmheFPTst6gHCN6hNOYbFEbejK3cxX8s0Bbg
> kXtqcrnnN+a+J5UZmFeB3tctQfwsVLyGcvcwzDRTjFCIjrD1CwdEd+Ckk740jCFU
> HXgEewO6rVnxAx80hP2c9ztsHblNt0KFm4zMtWjxmHTigac1EEA1ZAi5P3nIJu5n
> 7HIw0jVX3qZHamVHXWSPb7skEZY/wj7Kko8XmJFWS0bbwuaTQJ+Pr8ZJPT145/Tb
> F0w6PqPqiR9sre7Yvy4v9y/QOqFjujEqMzkTNedRaBEItmzELPkYBBms2b2bkIVj
> bMptV5FidCthzvJAnQ5efuiG9qYCuHajNEjQM4Mhu0t95yolmh4+yD2yxA4sS35W
> YPxy24tgY9A2nNpJS+QSWtCzkQBJz+0Uxnw8y3AbW2oRkA649i+9+KppSAqCx7kH
> QYUSwTD+7aETlVthfANEr5D/MbzJbflhTjXl/bZjuEc2p1tWPxZrqC+E8FwniMLL
> NYwK4rMDrSZfrgY7mn6uPcTxzEIMTj/KvtaZCFY1GRAlAf16vNVlnCHQzMvlYKGW
> gtqS2tF9DBurCs65qocxtWLAQwU=
> =bEIh
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Re: Enforcing server preference for cipher suites

[Peter Kreuser]

Harish,


> Am 10.10.2017 um 00:00 schrieb Harish Krishnan :
> 
> Thanks for the response, Chris.
> 
> Below are my answers in order.
> To keep the response as short as possible, i have not included the ciphers
> list in the connector -
> 
> a) Tomcat 7.0.79 (will be updating to 7.0.82)
> b) JRE 1.80_144
> c) Our connector configuration is below.
> d) We are using NIO.
> e) I am using a simple java client that makes TLS connection to our tomcat
> on below port. I am capturing the SSL handshake.
> The way i tested the client preference is: Lets take the same example i
> gave in my first email i.e. clients preference is ABCDEF and the tomcat
> servers preference is DEFABC with *useServerCipherSuitesOrder* set to true.
> During the 1st handshake connection, "A" cipher suite was chosen. I removed
> "A" from my tomcat connector, restarted the service, and did the connection
> test again.
> "B" was chosen during this 2nd handshake. Same test was continued and
> observed that CDEF were chosen next in order.
> I am expecting DEFABC as the order of preference as per the
> *useServerCipherSuitesOrder* setting.
> 
I believe that there is a misunderstanding. Your simple client does not seem to 
handle the situation correctly (even not at all).
I think if you request cipher B you will get B.

Please check with a ssl-tool like sslyze or testssl.sh. If your site is 
available on the internet, you could try ssllabs.com.

The settings seem to be OK, unless I do not see an incorrect formatting on my 
phone.

HTH,

Peter

> Let me know if i am missing anything or is my understanding is incorrect.
> 
> id="orion.server.https"
>acceptCount="100"
>*useServerCipherSuitesOrder*="true"
>ciphers="we have around 20 cipher suites listed..."
>clientAuth="want"
> 
> compressableMimeType="text/html,text/xml,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json"
>compression="on"
>compressionMinSize="2048"
>disableUploadTimeout="true"
>enableLookups="false"
>keystoreFile="keystore/xyz"
>keystorePass=""
>maxConnections="500"
>maxHttpHeaderSize="8192"
>maxKeepAliveRequests="500"
>maxThreads="250"
>minSpareThreads="25"
>noCompressionUserAgents="gozilla, traviata"
>port="8443"
>processorCache="500"
>protocol="org.apache.coyote.http11.Http11NioProtocol"
>scheme="https"
>secure="true"
>server="Undefined"
>sessionCacheSize="400"
>SSLEnabled="true"
>sslProtocol="TLS"
>sslEnabledProtocols="TLSv1.1, TLSv1.2"
>truststoreFile="keystore/xyz"
>truststorePass=""
>truststoreType="jks"
>URIEncoding="UTF-8" />
> 
> 
> On Mon, Oct 9, 2017 at 2:06 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Harish,
>> 
>>> On 10/9/17 12:31 PM, Harish Krishnan wrote:
>>> Need your expert input here. Not sure what I am doing wrong,  but I
>>> cannot get this server preference cipher suites feature working.
>>> 
>>> My setup: Latest tomcat 7.x build (which supports
>>> useServerCipherSuitesOrder attribute) Latest Java 1.8 build.
>>> 
>>> No matter what value I set to this attribute (true OR false OR
>>> undefined which is by default), I always see the Clients preference
>>> picked. As an example, if clients order is ABCDEF, and servers
>>> order is DEFABC, no matter what value I set to this
>>> useServerCipherSuitesOrder attribute, always the order selected is
>>> ABC...
>> 
>> What exact version of Tomcat are you using?
>> What exact version of Java are you using?
>> 
>> Please post your  configuration, minus any secrets.
>> 
>> Do you know if you are using the BIO, NIO, or APR connector?
>> 
>> How are you determining client-preference?
>> 
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> 
>> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnb5M4dHGNocmlzQGNo
>> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh+zxAAy11WLuuRfIQBdP/C
>> qt+eW8qFulTBX1eYGfNdCcTBnTRRTqpI1GVIT//XKkcqwLmh/0jwQSK1kRfkkHhK
>> j1V4djhQwoVtpNxP38WxsSr9yMczZNKK7OzTIEULeQqJJJTIUfGj00ayHIW/gp1p
>> MdqFw8CCwk4Xuwpz8PYeXgYPPq7EFvyU6ABs70rrJ7ZT0yRiJHQ/fmNdHekUa63s
>> n4+TB6BFzKIc11atGdpoHh4EXfaLMxeFWD6FVSH17FTQVqYxdDFQm32XcRgPP6If
>> xYPQpbN8Yb5dl2jhU1u9hvgGnDUccVCKooeEZ/fsu7whztNlR6bDl2lWVJkyO+m0
>> RJhCNI051iEf6+pbqlj2TaqeWjlxMFozLS8gwhO5usf/ZvrhYFkOanF2KRxkKaaR
>> /xwOvuSot06w+BVicbS0jbPiaEOux140ZUuPIxgi462mVIncYsW/oZvsbhrCoA7O
>>