Re: Context Dependency Injection with Tomcat 7.0 x / 8.0 x

[andreas]

Weld http://weld.cdi-spec.org/

Andreas




 On Thu, 06 Oct 2016 10:25:46 +0930 Christopher 
Schultz wrote  
 > -BEGIN PGP SIGNED MESSAGE- 
 > Hash: SHA256 
 >  
 > Kiran, 
 >  
 > On 10/5/16 8:15 PM, Kiran Badi wrote: 
 > > I wanted to check if their is a way to do CDI with Tomcat for 7x 
 > > and 8x version as per JEE spec ? 
 >  
 > What part of the JEE spec includes CDI? 
 >  
 > > I have a project for which I wanted to use CDI the way spring does 
 > > it. 
 >  
 > You can certainly use Spring for that. 
 >  
 > > Appreciate if someone can suggest something. 
 >  
 > There are many CDI frameworks., but Spring seems to have taken over 
 > the world when it comes to CDI. 
 >  
 > - -chris 




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

Re: Proxy Apache https to Tomcat http

[Ted Spradley]

Chris,

On Wed, Oct 5, 2016 at 7:52 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Ted,
>
> On 10/5/16 6:47 PM, Ted Spradley wrote:
> > Chris,
> >
> > On Wed, Oct 5, 2016 at 5:14 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Ted,
> >
> > On 10/5/16 6:10 PM, Ted Spradley wrote:
>  Chris,
> 
>  Thanks for your response.
> 
>  On Wed, Oct 5, 2016 at 3:14 PM, Christopher Schultz <
>  ch...@christopherschultz.net> wrote:
> 
>  Ted,
> 
>  On 10/5/16 3:42 PM, TED SPRADLEY wrote:
> >>> Tomcat 7.0.68 Apache 2.4.6 CentOS  7.2.1511
> 
>  Thanks.
> 
> >>> Problem: A Tomcat application at context "/mycontext"
> >>> on port 8081 running through Apache proxy renders as
> >>> expected when using http://example.com/mycontext but
> >>> https://example.com/mycontext call renders "The
> >>> requested URL /mycontext/ was not found on this
> >>> server."
> >>>
> >>> Question: Do I have a Tomcat Connector configuration
> >>> problem? Or an Apache proxy configuration problem? Or
> >>> an Apache ssl.conf problem?
> >>>
> >>> Note: the CA issued certificate appears to be properly
> >>> installed as evidence by the lock icon in the url bar
> >>> displaying "Verified by Š " when doing a mouseover.
> >>>
> >>> Files: Httpd.conf -  ServerName
> >>> www.example.com ServerAlias *.example.com ProxyRequests
> >>> off ProxyPass /mycontext
> >>> http://example.com:8081/mycontext ProxyPassReverse
> >>> /mycontext http://example.com:8081/mycontext
> >>>   ProxyRequests off
> >>> ProxyPreserveHost on SSLEngine on SSLCertificateFile
> >>> /path/to/certs/ca.crt SSLCertificateKeyFile
> >>> /path/to/key/private/exampleDotCom.key ServerName
> >>> www.example.com ServerAlias *.example.com ProxyPass
> >>> /mycontext http://example.com:8081/mycontext
> >>> ProxyPassReverse /mycontext
> >>> http://example.com:8081/mycontext 
> 
>  On first inspection, that looks correct.
> 
> >>> Tomcat's server.xml Connector  >>> protocol="HTTP/1.1" connectionTimeout="2"
> >>> proxyName="www.example.com" proxyPort="80"
> >>> redirectPort="8443" xpoweredBy="false" server="Apache
> >>> TomEE" />
> 
>  That also looks correct.
> 
>  How have you deployed your actual application?
> 
> 
> > Yes. It is deployed and responds as expected through the
> > proxy when using http.
> >
> > Great. But *HOW* have you deployed your actual application?
> >
> >
> >> Sorry, I missed the "How". I'm not sure what descriptors you are
> >> asking for when you ask how.
>
> Auto-deployed WAR file/directory? WAR/dir deployed via manager
> application? Explicit descriptor XML file placed in
> CATALINA_HOME/conf/[service]/[host]/[app].xml?
>
> Ah, yes.
1. WAR/dir deployed via manager application in
CATALINA_HOME/conf/Catalina/[host]/manager.xml
2. App directory is CATALINA_HOME/mycontextapps/mycontext/
with web.xml in CATALINA_HOME/mycontextapps/mycontext/WEB-INF/web.xml

I didn't dream up this location, I followed some example deployment of
multiple domains
with multiple apps each. Is the location of the app files causing the
problem? The multiple
domains with multiple apps all respond as expected using the proxy with
virtualhost *:80.

- Ted

- -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJX9aA5AAoJEBzwKT+lPKRYoxAP/2KTSxTMFqtpm3gYOphW1B1N
> Tx56YMCETDtihjLCtWuLQt0QSZ/u92Lbd+xg/aCM9SdkrQQkSby+h2oJuT2E5Dpb
> LkWpeODS1xp93l0UO4eTp1RW46ToHZHlVABlYDkr27LPrIqYrtntyCLNPTr3N1Xo
> ExBzvZxxM5C36uDVtnrrNxay/qKpq/sOJaW84yc161eXhrHvXh5wQF76hTGJswbs
> OQapt+VCzDRcaQVeHpBXm6JvfSwFfjbflgpAcPen/Mwu1sgqeNicOKNd5kBnL2pJ
> 7NOEyMIJnVMaZ9hdu/9HF4fVo307ix7n2yjm3JAMZcb3+2GRD3Zw8e6/+YIk7gRI
> 8n8I8Q/zW8qEG9S5jqsX7Gb7wF2ZZUKc7xOOpGQy4Ctoa0RizFxipfQB77OhNzeu
> 9txqUgks+AvjVV3aCEWMeyqhC9n8QPxws3Sc9A8MxQ4IqII9KWgsP3tQT2iqZukj
> kXH1L5ELbe4CIFQBCxVS4BsvnFzGm96iz4DzkIRUnHGL0ipHXoWlQBXPjxFwudw2
> N7Ln+os14LZvnHFLSV1UDpEkB7pfWvIRAiRqavYx42gPpwXxx3MiImuevr+LDRbw
> ublChOTt1yzsWNQIYspwGt8srDtBIW7rZZggqVmds9NmD+d3tLHoxfJ3bm7Cc9qA
> lm7rwoaI3foiJ2Jnpn0D
> =B1CN
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Context Dependency Injection with Tomcat 7.0 x / 8.0 x

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Kiran,

On 10/5/16 8:15 PM, Kiran Badi wrote:
> I wanted to check if their is a way to do CDI with Tomcat for 7x
> and 8x version as per JEE spec ?

What part of the JEE spec includes CDI?

> I have a project for which I wanted to use CDI the way spring does
> it.

You can certainly use Spring for that.

> Appreciate if someone can suggest something.

There are many CDI frameworks., but Spring seems to have taken over
the world when it comes to CDI.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJX9aESAAoJEBzwKT+lPKRYm8YP/jTF3F62xeluLYfz9ezKNT5u
eqUtyFi2gzOZ1IRgcscnOWf8Wpe3gEL1R/B16qMfmbdRb21esCOvpAH0vzqByamK
hD1AmrShLyoAJrZpqUwPxjWxKSjLgC6WOonCHIL+JeeHl58xwjH6NdwD6fWcsZDj
nkTVYJTbtmSpR8uA3P/wagfq7ngzVL77Idrvg81iQr0wQYCXpgQPkn1TGNvke/I8
2oeyOWiijAnJxpz4cyod67WhtnfrxSib8/i9FRtvifndvA2+AZIV/Vb86GUwjneO
aYzhlHS3E+TCEflhjYYf42Jw7sLNKj6OIdafX1ukMl1Rv605J1XUcTpJFYQ70MkB
P3pys07cnYvG85ZFZRA0ttj2NCl7wAPaBoL6rJoLJ0q2+WRyH5Cte03xizbKDzWI
7uHZDXvgMuKjmKWt9A5Db1W3VkNzsWy7T8kFXcGkSHxBrQZeRdqZZxybQKAYGOmM
PvWXdyq9Dy7JON8Wv4J0hCzDSoPb8aB0VLVN+CQgPmoPOJC1dEI+elwEABMEa19M
TU+jww6oDeZXk1iZ/vtMws2YnadtbrImTdNhQ94slFRjb0tbhicTOMkr96/chxFB
n66Y92gr7dU7wZHs9JsvGNr6YJKhgAAdWu3CZJWrrPh1zUzoxbqc2lux73qZhAQw
qA4TTEpEkbzYVboyvIt4
=84v2
-END PGP SIGNATURE-

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

Re: Proxy Apache https to Tomcat http

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ted,

On 10/5/16 6:47 PM, Ted Spradley wrote:
> Chris,
> 
> On Wed, Oct 5, 2016 at 5:14 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Ted,
> 
> On 10/5/16 6:10 PM, Ted Spradley wrote:
 Chris,
 
 Thanks for your response.
 
 On Wed, Oct 5, 2016 at 3:14 PM, Christopher Schultz < 
 ch...@christopherschultz.net> wrote:
 
 Ted,
 
 On 10/5/16 3:42 PM, TED SPRADLEY wrote:
>>> Tomcat 7.0.68 Apache 2.4.6 CentOS  7.2.1511
 
 Thanks.
 
>>> Problem: A Tomcat application at context "/mycontext"
>>> on port 8081 running through Apache proxy renders as
>>> expected when using http://example.com/mycontext but 
>>> https://example.com/mycontext call renders "The
>>> requested URL /mycontext/ was not found on this
>>> server."
>>> 
>>> Question: Do I have a Tomcat Connector configuration
>>> problem? Or an Apache proxy configuration problem? Or
>>> an Apache ssl.conf problem?
>>> 
>>> Note: the CA issued certificate appears to be properly 
>>> installed as evidence by the lock icon in the url bar 
>>> displaying "Verified by Š " when doing a mouseover.
>>> 
>>> Files: Httpd.conf -  ServerName 
>>> www.example.com ServerAlias *.example.com ProxyRequests
>>> off ProxyPass /mycontext
>>> http://example.com:8081/mycontext ProxyPassReverse
>>> /mycontext http://example.com:8081/mycontext
>>>   ProxyRequests off
>>> ProxyPreserveHost on SSLEngine on SSLCertificateFile
>>> /path/to/certs/ca.crt SSLCertificateKeyFile
>>> /path/to/key/private/exampleDotCom.key ServerName
>>> www.example.com ServerAlias *.example.com ProxyPass
>>> /mycontext http://example.com:8081/mycontext 
>>> ProxyPassReverse /mycontext
>>> http://example.com:8081/mycontext 
 
 On first inspection, that looks correct.
 
>>> Tomcat's server.xml Connector >> protocol="HTTP/1.1" connectionTimeout="2" 
>>> proxyName="www.example.com" proxyPort="80" 
>>> redirectPort="8443" xpoweredBy="false" server="Apache
>>> TomEE" />
 
 That also looks correct.
 
 How have you deployed your actual application?
 
 
> Yes. It is deployed and responds as expected through the
> proxy when using http.
> 
> Great. But *HOW* have you deployed your actual application?
> 
> 
>> Sorry, I missed the "How". I'm not sure what descriptors you are
>> asking for when you ask how.

Auto-deployed WAR file/directory? WAR/dir deployed via manager
application? Explicit descriptor XML file placed in
CATALINA_HOME/conf/[service]/[host]/[app].xml?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJX9aA5AAoJEBzwKT+lPKRYoxAP/2KTSxTMFqtpm3gYOphW1B1N
Tx56YMCETDtihjLCtWuLQt0QSZ/u92Lbd+xg/aCM9SdkrQQkSby+h2oJuT2E5Dpb
LkWpeODS1xp93l0UO4eTp1RW46ToHZHlVABlYDkr27LPrIqYrtntyCLNPTr3N1Xo
ExBzvZxxM5C36uDVtnrrNxay/qKpq/sOJaW84yc161eXhrHvXh5wQF76hTGJswbs
OQapt+VCzDRcaQVeHpBXm6JvfSwFfjbflgpAcPen/Mwu1sgqeNicOKNd5kBnL2pJ
7NOEyMIJnVMaZ9hdu/9HF4fVo307ix7n2yjm3JAMZcb3+2GRD3Zw8e6/+YIk7gRI
8n8I8Q/zW8qEG9S5jqsX7Gb7wF2ZZUKc7xOOpGQy4Ctoa0RizFxipfQB77OhNzeu
9txqUgks+AvjVV3aCEWMeyqhC9n8QPxws3Sc9A8MxQ4IqII9KWgsP3tQT2iqZukj
kXH1L5ELbe4CIFQBCxVS4BsvnFzGm96iz4DzkIRUnHGL0ipHXoWlQBXPjxFwudw2
N7Ln+os14LZvnHFLSV1UDpEkB7pfWvIRAiRqavYx42gPpwXxx3MiImuevr+LDRbw
ublChOTt1yzsWNQIYspwGt8srDtBIW7rZZggqVmds9NmD+d3tLHoxfJ3bm7Cc9qA
lm7rwoaI3foiJ2Jnpn0D
=B1CN
-END PGP SIGNATURE-

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

Context Dependency Injection with Tomcat 7.0 x / 8.0 x

[Kiran Badi]

Hi All,

I wanted to check if their is a way to do CDI with Tomcat for 7x and 8x
version as per JEE spec ?

I have a project for which I wanted to use CDI the way spring does it.

Appreciate if someone can suggest something.


- Kiran

Re: Proxy Apache https to Tomcat http

[Ted Spradley]

Chris,

On Wed, Oct 5, 2016 at 5:14 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Ted,
>
> On 10/5/16 6:10 PM, Ted Spradley wrote:
> > Chris,
> >
> > Thanks for your response.
> >
> > On Wed, Oct 5, 2016 at 3:14 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Ted,
> >
> > On 10/5/16 3:42 PM, TED SPRADLEY wrote:
>  Tomcat 7.0.68 Apache 2.4.6 CentOS  7.2.1511
> >
> > Thanks.
> >
>  Problem: A Tomcat application at context "/mycontext" on port
>  8081 running through Apache proxy renders as expected when
>  using http://example.com/mycontext but
>  https://example.com/mycontext call renders "The requested URL
>  /mycontext/ was not found on this server."
> 
>  Question: Do I have a Tomcat Connector configuration problem?
>  Or an Apache proxy configuration problem? Or an Apache
>  ssl.conf problem?
> 
>  Note: the CA issued certificate appears to be properly
>  installed as evidence by the lock icon in the url bar
>  displaying "Verified by Š " when doing a mouseover.
> 
>  Files: Httpd.conf -  ServerName
>  www.example.com ServerAlias *.example.com ProxyRequests off
>  ProxyPass /mycontext  http://example.com:8081/mycontext
>  ProxyPassReverse /mycontext
>  http://example.com:8081/mycontext    *:443> ProxyRequests off ProxyPreserveHost on SSLEngine on
>  SSLCertificateFile /path/to/certs/ca.crt
>  SSLCertificateKeyFile /path/to/key/private/exampleDotCom.key
>  ServerName www.example.com ServerAlias *.example.com
>  ProxyPass /mycontext http://example.com:8081/mycontext
>  ProxyPassReverse /mycontext http://example.com:8081/mycontext
>  
> >
> > On first inspection, that looks correct.
> >
>  Tomcat's server.xml Connector   protocol="HTTP/1.1" connectionTimeout="2"
>  proxyName="www.example.com" proxyPort="80"
>  redirectPort="8443" xpoweredBy="false" server="Apache TomEE"
>  />
> >
> > That also looks correct.
> >
> > How have you deployed your actual application?
> >
> >
> >> Yes. It is deployed and responds as expected through the proxy
> >> when using http.
>
> Great. But *HOW* have you deployed your actual application?
>

Sorry, I missed the "How". I'm not sure what descriptors you are asking for
when you
ask how.


> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJX9XsvAAoJEBzwKT+lPKRYYJYQALKX6jEiUlcQQ2fXCq6a017F
> /6rVjJ36ptaaQQ6O2xYLDI+efHASKK0swg6zwxtR10F9PepcXKreTGIGjvzT4vG3
> hvXuWtrKRVyOXDAhkdzXjAmwdovj+3vRf7Qm+GrpAMCI+Fi/GYyCsW2a7Opdlhnh
> fWTwz3PVcuJ0+N7wFX55hChm0NjX9P1T6CLxJ7k1Q//vr+PqBUyJiNO1FRuoS1+D
> vJOI2Ixm7E/tXCRc81aZA572fXIV78gcJmbHkERpy5WOW+G6UIG1XKNxqF4Afpqj
> bL8dPNj22fZRu/qyIpYGVdMfyaSFkbfWP8jM8eQS9fLs9t+BPgzyt/Z0wxhsEVDT
> EY/E9qAUr2Ai3TFlgZOz79ED1VQkVDTMlpZQ/w9XsyLjT518KKPBT6v665wVfeaV
> N+uxoIGj4Ew37Xcm2RAXkv5BuomdqhtkpJ2n/BZ/pXxUQwpo57mDyBUDoVnSouuS
> eC+vmcjroeq73dPE07PNRJpphjw8K5uZCo+en+qH1kVhwe2O8JNtjy5wkjslcdKF
> +2vwlUFdoPO+8bhNu8PfsK6XZOJ0Uejf7iogb8OXr3SRjPF8qYnz28OBiAV3NC5E
> dq8Do2mFWcWFTi+uV9axQl4+iAr+3P/g8sZJ8CTtySFfQBmBJky6xOIKtbshxRiI
> mdFOlM+R4jw1wnwWE5Hp
> =kOrd
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [OT] ECDHE cipher suites missing on Amazon Linux / OpenJDK 7 and 8 ??

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rainer,

On 10/5/16 6:13 PM, Christopher Schultz wrote:
> Rainer,
> 
> On 10/5/16 4:52 PM, Rainer Jung wrote:
>> Am 05.10.2016 um 21:11 schrieb Christopher Schultz:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>> 
>>> All,
>>> 
>>> Apologies for off-topic post, but lots of folks here have lots 
>>> of different experiences and maybe someone has come across
>>> this.
>>> 
>>> I've got a few servers in Amazon EC2 running Amazon Linux. I'm 
>>> using the OpenJDK package, and I have versions 1.7.0 and 1.8.0 
>>> running side-by-side:
>>> 
>>> $ java -version java version "1.7.0_111" OpenJDK Runtime 
>>> Environment (amzn-2.6.7.2.68.amzn1-i386 u111-b01) OpenJDK
>>> Client VM (build 24.111-b01, mixed mode, sharing)
>>> 
>>> $ java8 -version openjdk version "1.8.0_101" OpenJDK Runtime 
>>> Environment (build 1.8.0_101-b13) OpenJDK Server VM (build 
>>> 25.101-b13, mixed mode)
>>> 
>>> For some reason, a whole slew of crypto support is flat-out 
>>> /missing/ from those packages (java-1.7.0-openjdk and 
>>> java-1.8.0-openjdk). Here's what I get when I run my SSLInfo
>>> tool on the box:
>>> 
>>> $ java -showversion -classpath libs/chadis-tools-1.55.jar 
>>> com.chadis.tools.security.SSLInfo java version "1.7.0_111" 
>>> OpenJDK Runtime Environment (amzn-2.6.7.2.68.amzn1-i386 
>>> u111-b01) OpenJDK Client VM (build 24.111-b01, mixed mode, 
>>> sharing)
>>> 
>>> Supported SSL Protocols: TLSv1 (SunJSSE) TLSv1.1 (SunJSSE) 
>>> TLSv1.2 (SunJSSE) DefaultCipher Name 
>>> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * 
>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA
>>>  SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * 
>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA
>>>  SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA 
>>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 
>>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA
>>>  SSL_DH_anon_WITH_RC4_128_MD5 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
>>>  SSL_RSA_EXPORT_WITH_RC4_40_MD5 * SSL_RSA_WITH_3DES_EDE_CBC_SHA
>>> SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5
>>> SSL_RSA_WITH_NULL_SHA SSL_RSA_WITH_RC4_128_MD5
>>> SSL_RSA_WITH_RC4_128_SHA * TLS_DHE_DSS_WITH_AES_128_CBC_SHA * 
>>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 * 
>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA * 
>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 * 
>>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA * 
>>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 * 
>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA * 
>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 
>>> TLS_DH_anon_WITH_AES_128_CBC_SHA 
>>> TLS_DH_anon_WITH_AES_128_CBC_SHA256 
>>> TLS_DH_anon_WITH_AES_256_CBC_SHA 
>>> TLS_DH_anon_WITH_AES_256_CBC_SHA256 * 
>>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV 
>>> TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 
>>> TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA 
>>> TLS_KRB5_EXPORT_WITH_RC4_40_MD5 TLS_KRB5_EXPORT_WITH_RC4_40_SHA
>>>  TLS_KRB5_WITH_3DES_EDE_CBC_MD5 TLS_KRB5_WITH_3DES_EDE_CBC_SHA
>>>  TLS_KRB5_WITH_DES_CBC_MD5 TLS_KRB5_WITH_DES_CBC_SHA 
>>> TLS_KRB5_WITH_RC4_128_MD5 TLS_KRB5_WITH_RC4_128_SHA * 
>>> TLS_RSA_WITH_AES_128_CBC_SHA * TLS_RSA_WITH_AES_128_CBC_SHA256
>>> * TLS_RSA_WITH_AES_256_CBC_SHA * 
>>> TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_NULL_SHA256
>>> 
>>> Note the complete lack of ECDH or ECDHE cipher suites. Now
>>> again with Java 8:
>>> 
>>> $ java8 -showversion -classpath libs/chadis-tools-1.55.jar 
>>> com.chadis.tools.security.SSLInfo openjdk version "1.8.0_101" 
>>> OpenJDK Runtime Environment (build 1.8.0_101-b13) OpenJDK
>>> Server VM (build 25.101-b13, mixed mode)
>>> 
>>> Supported SSL Protocols: TLS (SunJSSE) TLSv1 (SunJSSE) TLSv1.1 
>>> (SunJSSE) TLSv1.2 (SunJSSE) DefaultCipher Name 
>>> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * 
>>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA
>>>  SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * 
>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA
>>>  SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA 
>>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 
>>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA
>>>  SSL_DH_anon_WITH_RC4_128_MD5 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
>>>  SSL_RSA_EXPORT_WITH_RC4_40_MD5 * SSL_RSA_WITH_3DES_EDE_CBC_SHA
>>> SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_NULL_MD5
>>> SSL_RSA_WITH_NULL_SHA SSL_RSA_WITH_RC4_128_MD5
>>> SSL_RSA_WITH_RC4_128_SHA * TLS_DHE_DSS_WITH_AES_128_CBC_SHA * 
>>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 * 
>>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 * 
>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA * 
>>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 * 
>>> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 * 
>>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA * 
>>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 * 
>>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 * 
>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA * 
>>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 * 
>>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 
>>> TLS_DH_anon_WITH_AES_128_CBC_SHA 
>>> TLS_DH_anon_WITH_AES_128_CBC_SHA256 
>>> TLS_DH_anon_WITH_AES_128_GCM_SHA256 
>>> TLS_DH_anon_WITH_AES_256_CBC_SHA 
>>> 

Re: Proxy Apache https to Tomcat http

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ted,

On 10/5/16 6:10 PM, Ted Spradley wrote:
> Chris,
> 
> Thanks for your response.
> 
> On Wed, Oct 5, 2016 at 3:14 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Ted,
> 
> On 10/5/16 3:42 PM, TED SPRADLEY wrote:
 Tomcat 7.0.68 Apache 2.4.6 CentOS  7.2.1511
> 
> Thanks.
> 
 Problem: A Tomcat application at context "/mycontext" on port
 8081 running through Apache proxy renders as expected when
 using http://example.com/mycontext but
 https://example.com/mycontext call renders "The requested URL
 /mycontext/ was not found on this server."
 
 Question: Do I have a Tomcat Connector configuration problem?
 Or an Apache proxy configuration problem? Or an Apache
 ssl.conf problem?
 
 Note: the CA issued certificate appears to be properly
 installed as evidence by the lock icon in the url bar
 displaying "Verified by Š " when doing a mouseover.
 
 Files: Httpd.conf -  ServerName
 www.example.com ServerAlias *.example.com ProxyRequests off
 ProxyPass /mycontext  http://example.com:8081/mycontext
 ProxyPassReverse /mycontext
 http://example.com:8081/mycontext  >>> *:443> ProxyRequests off ProxyPreserveHost on SSLEngine on
 SSLCertificateFile /path/to/certs/ca.crt 
 SSLCertificateKeyFile /path/to/key/private/exampleDotCom.key 
 ServerName www.example.com ServerAlias *.example.com
 ProxyPass /mycontext http://example.com:8081/mycontext
 ProxyPassReverse /mycontext http://example.com:8081/mycontext
 
> 
> On first inspection, that looks correct.
> 
 Tomcat's server.xml Connector >>> protocol="HTTP/1.1" connectionTimeout="2" 
 proxyName="www.example.com" proxyPort="80"
 redirectPort="8443" xpoweredBy="false" server="Apache TomEE"
 />
> 
> That also looks correct.
> 
> How have you deployed your actual application?
> 
> 
>> Yes. It is deployed and responds as expected through the proxy
>> when using http.

Great. But *HOW* have you deployed your actual application?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJX9XsvAAoJEBzwKT+lPKRYYJYQALKX6jEiUlcQQ2fXCq6a017F
/6rVjJ36ptaaQQ6O2xYLDI+efHASKK0swg6zwxtR10F9PepcXKreTGIGjvzT4vG3
hvXuWtrKRVyOXDAhkdzXjAmwdovj+3vRf7Qm+GrpAMCI+Fi/GYyCsW2a7Opdlhnh
fWTwz3PVcuJ0+N7wFX55hChm0NjX9P1T6CLxJ7k1Q//vr+PqBUyJiNO1FRuoS1+D
vJOI2Ixm7E/tXCRc81aZA572fXIV78gcJmbHkERpy5WOW+G6UIG1XKNxqF4Afpqj
bL8dPNj22fZRu/qyIpYGVdMfyaSFkbfWP8jM8eQS9fLs9t+BPgzyt/Z0wxhsEVDT
EY/E9qAUr2Ai3TFlgZOz79ED1VQkVDTMlpZQ/w9XsyLjT518KKPBT6v665wVfeaV
N+uxoIGj4Ew37Xcm2RAXkv5BuomdqhtkpJ2n/BZ/pXxUQwpo57mDyBUDoVnSouuS
eC+vmcjroeq73dPE07PNRJpphjw8K5uZCo+en+qH1kVhwe2O8JNtjy5wkjslcdKF
+2vwlUFdoPO+8bhNu8PfsK6XZOJ0Uejf7iogb8OXr3SRjPF8qYnz28OBiAV3NC5E
dq8Do2mFWcWFTi+uV9axQl4+iAr+3P/g8sZJ8CTtySFfQBmBJky6xOIKtbshxRiI
mdFOlM+R4jw1wnwWE5Hp
=kOrd
-END PGP SIGNATURE-

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

Re: [OT] ECDHE cipher suites missing on Amazon Linux / OpenJDK 7 and 8 ??

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rainer,

On 10/5/16 4:52 PM, Rainer Jung wrote:
> Am 05.10.2016 um 21:11 schrieb Christopher Schultz:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> All,
>> 
>> Apologies for off-topic post, but lots of folks here have lots
>> of different experiences and maybe someone has come across this.
>> 
>> I've got a few servers in Amazon EC2 running Amazon Linux. I'm
>> using the OpenJDK package, and I have versions 1.7.0 and 1.8.0
>> running side-by-side:
>> 
>> $ java -version java version "1.7.0_111" OpenJDK Runtime
>> Environment (amzn-2.6.7.2.68.amzn1-i386 u111-b01) OpenJDK Client
>> VM (build 24.111-b01, mixed mode, sharing)
>> 
>> $ java8 -version openjdk version "1.8.0_101" OpenJDK Runtime
>> Environment (build 1.8.0_101-b13) OpenJDK Server VM (build
>> 25.101-b13, mixed mode)
>> 
>> For some reason, a whole slew of crypto support is flat-out
>> /missing/ from those packages (java-1.7.0-openjdk and
>> java-1.8.0-openjdk). Here's what I get when I run my SSLInfo tool
>> on the box:
>> 
>> $ java -showversion -classpath libs/chadis-tools-1.55.jar 
>> com.chadis.tools.security.SSLInfo java version "1.7.0_111" 
>> OpenJDK Runtime Environment (amzn-2.6.7.2.68.amzn1-i386
>> u111-b01) OpenJDK Client VM (build 24.111-b01, mixed mode,
>> sharing)
>> 
>> Supported SSL Protocols: TLSv1 (SunJSSE) TLSv1.1 (SunJSSE) 
>> TLSv1.2 (SunJSSE) DefaultCipher Name 
>> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA *
>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA 
>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA *
>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA 
>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA 
>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 
>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA 
>> SSL_DH_anon_WITH_RC4_128_MD5 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA 
>> SSL_RSA_EXPORT_WITH_RC4_40_MD5 *
>> SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA 
>> SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA 
>> SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA *
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA *
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 *
>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA *
>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 *
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA *
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 *
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA *
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 
>> TLS_DH_anon_WITH_AES_128_CBC_SHA 
>> TLS_DH_anon_WITH_AES_128_CBC_SHA256 
>> TLS_DH_anon_WITH_AES_256_CBC_SHA 
>> TLS_DH_anon_WITH_AES_256_CBC_SHA256 *
>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV 
>> TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 
>> TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA 
>> TLS_KRB5_EXPORT_WITH_RC4_40_MD5 TLS_KRB5_EXPORT_WITH_RC4_40_SHA 
>> TLS_KRB5_WITH_3DES_EDE_CBC_MD5 TLS_KRB5_WITH_3DES_EDE_CBC_SHA 
>> TLS_KRB5_WITH_DES_CBC_MD5 TLS_KRB5_WITH_DES_CBC_SHA 
>> TLS_KRB5_WITH_RC4_128_MD5 TLS_KRB5_WITH_RC4_128_SHA *
>> TLS_RSA_WITH_AES_128_CBC_SHA *
>> TLS_RSA_WITH_AES_128_CBC_SHA256 *
>> TLS_RSA_WITH_AES_256_CBC_SHA *
>> TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_NULL_SHA256
>> 
>> Note the complete lack of ECDH or ECDHE cipher suites. Now again
>> with Java 8:
>> 
>> $ java8 -showversion -classpath libs/chadis-tools-1.55.jar 
>> com.chadis.tools.security.SSLInfo openjdk version "1.8.0_101" 
>> OpenJDK Runtime Environment (build 1.8.0_101-b13) OpenJDK Server
>> VM (build 25.101-b13, mixed mode)
>> 
>> Supported SSL Protocols: TLS (SunJSSE) TLSv1 (SunJSSE) TLSv1.1
>> (SunJSSE) TLSv1.2 (SunJSSE) DefaultCipher Name 
>> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA *
>> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA 
>> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA *
>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA 
>> SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA 
>> SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 
>> SSL_DH_anon_WITH_3DES_EDE_CBC_SHA SSL_DH_anon_WITH_DES_CBC_SHA 
>> SSL_DH_anon_WITH_RC4_128_MD5 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA 
>> SSL_RSA_EXPORT_WITH_RC4_40_MD5 *
>> SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA 
>> SSL_RSA_WITH_NULL_MD5 SSL_RSA_WITH_NULL_SHA 
>> SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA *
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA *
>> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 *
>> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 *
>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA *
>> TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 *
>> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 *
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA *
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 *
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 *
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA *
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 *
>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 
>> TLS_DH_anon_WITH_AES_128_CBC_SHA 
>> TLS_DH_anon_WITH_AES_128_CBC_SHA256 
>> TLS_DH_anon_WITH_AES_128_GCM_SHA256 
>> TLS_DH_anon_WITH_AES_256_CBC_SHA 
>> TLS_DH_anon_WITH_AES_256_CBC_SHA256 
>> TLS_DH_anon_WITH_AES_256_GCM_SHA384 *
>> TLS_EMPTY_RENEGOTIATION_INFO_SCSV 
>> TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 
>> TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA 
>> 

Re: Proxy Apache https to Tomcat http

[Ted Spradley]

Chris,

Thanks for your response.

On Wed, Oct 5, 2016 at 3:14 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Ted,
>
> On 10/5/16 3:42 PM, TED SPRADLEY wrote:
> > Tomcat 7.0.68 Apache 2.4.6 CentOS  7.2.1511
>
> Thanks.
>
> > Problem: A Tomcat application at context "/mycontext" on port 8081
> > running through Apache proxy renders as expected when using
> > http://example.com/mycontext but https://example.com/mycontext call
> > renders "The requested URL /mycontext/ was not found on this
> > server."
> >
> > Question: Do I have a Tomcat Connector configuration problem? Or an
> > Apache proxy configuration problem? Or an Apache ssl.conf problem?
> >
> > Note: the CA issued certificate appears to be properly installed as
> > evidence by the lock icon in the url bar displaying "Verified by Š
> > " when doing a mouseover.
> >
> > Files: Httpd.conf -  ServerName www.example.com
> > ServerAlias *.example.com ProxyRequests off ProxyPass
> > /mycontext  http://example.com:8081/mycontext ProxyPassReverse
> > /mycontext  http://example.com:8081/mycontext 
> >  ProxyRequests off ProxyPreserveHost on
> > SSLEngine on SSLCertificateFile /path/to/certs/ca.crt
> > SSLCertificateKeyFile /path/to/key/private/exampleDotCom.key
> > ServerName www.example.com ServerAlias *.example.com ProxyPass
> > /mycontext http://example.com:8081/mycontext ProxyPassReverse
> > /mycontext http://example.com:8081/mycontext 
>
> On first inspection, that looks correct.
>
> > Tomcat's server.xml Connector  > protocol="HTTP/1.1" connectionTimeout="2"
> > proxyName="www.example.com" proxyPort="80" redirectPort="8443"
> > xpoweredBy="false" server="Apache TomEE" />
>
> That also looks correct.
>
> How have you deployed your actual application?
>

Yes. It is deployed and responds as expected through the proxy when using
http.


> > Ssl.conf - SSLEngine on
> >
> > SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA
> >
> > SSLCertificateFile /path/to/certs/ca.crt
> >
> > SSLCertificateKeyFile /path/to/key/private/exampleDotCom.key
> >
> > SSLCACertificateFile /path/to/bundle/ca_bundle.crt
>
> Is ssl.conf actually included anywhere?
>

Yes. ssl.conf full path is /etc/httpd/conf.d/ssl.conf.

>From httpd.conf

# Load config files in the "/etc/httpd/conf.d" directory, if any.
IncludeOptional conf.d/*.conf


> You will probably also want to use the RemoteIPValve and possibly the
> SSLValve as well. Have a look at Tomcat's proxy support valves here:
>
> https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Proxies_Support
>

Thank you. I'll read the Proxies Support and implement.


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJX9V9AAAoJEBzwKT+lPKRYL4YP/0KGogACGY7Ul3K59sMky8mz
> tKjFmBU+jLk6DgyvUv6wI5ZcCRLukZsN6vvDU2psiIpGruakQjLfDtiDyPKnBGb3
> G6jmvdfCNPfp9eWRMAKvI90tEvZ10g8/Qbzfp7XZ8tAOuoFSkxyoVYRrZMCoLUYq
> UPCVsJQxhu5yFqzDzAz1AJN26b25Q2+F1W8GznCWz3pjmBjI44Y+y3FwlBVeayGZ
> QaXp+VCzsKw4RRlUy8uO6KH63GgLvNWFZM3gYE85231Eu9RhtQREZNQG/geufnSD
> 3fy6pSQ1GvP+o2giUEgS0ik3zYjzmomtGGpbDQH2wCMuXTMJbJBM4iQZnhZ6Wz1Z
> oDY6BRHvq+sTiEyJ4Ln6sKFymKccg3XSkwZ5UWHR+WA9NabyyEb7Li3AFYkpsyjk
> o93QgPNqbzVBEmbsQTlsb/pfPPc3KoeCDRm5SLtMmPn9zDWHg30q0MGYbz8U96r8
> cojk8k634UQ+B2q36IZpcZh6Ah295bU+I73JUh6T9RF1EcN8PgqOcH4cC7S10fV+
> fiFqdz8XmV372jiiY1jk2Ka6SdJiYUo/froCUHlaNIsThMZra+D6woK55PO0e1yF
> 0HCAMEGAH+bwhJB5UgUj/4rHdcVHO32GRuH0jKpUauhfBh6/k385C58iw4ONsxyG
> Iwa3OPXi7GUSCrWJ0lxr
> =m3nm
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: [OT] ECDHE cipher suites missing on Amazon Linux / OpenJDK 7 and 8 ??

[Rainer Jung]

Am 05.10.2016 um 21:11 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Apologies for off-topic post, but lots of folks here have lots of
different experiences and maybe someone has come across this.

I've got a few servers in Amazon EC2 running Amazon Linux. I'm using
the OpenJDK package, and I have versions 1.7.0 and 1.8.0 running
side-by-side:

$ java -version
java version "1.7.0_111"
OpenJDK Runtime Environment (amzn-2.6.7.2.68.amzn1-i386 u111-b01)
OpenJDK Client VM (build 24.111-b01, mixed mode, sharing)

$ java8 -version
openjdk version "1.8.0_101"
OpenJDK Runtime Environment (build 1.8.0_101-b13)
OpenJDK Server VM (build 25.101-b13, mixed mode)

For some reason, a whole slew of crypto support is flat-out /missing/
from those packages (java-1.7.0-openjdk and java-1.8.0-openjdk).
Here's what I get when I run my SSLInfo tool on the box:

$ java -showversion -classpath libs/chadis-tools-1.55.jar
com.chadis.tools.security.SSLInfo
java version "1.7.0_111"
OpenJDK Runtime Environment (amzn-2.6.7.2.68.amzn1-i386 u111-b01)
OpenJDK Client VM (build 24.111-b01, mixed mode, sharing)

Supported SSL Protocols:
  TLSv1 (SunJSSE)
  TLSv1.1 (SunJSSE)
  TLSv1.2 (SunJSSE)
Default Cipher Name
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
*   SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA256
*   TLS_EMPTY_RENEGOTIATION_INFO_SCSV
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
TLS_KRB5_EXPORT_WITH_RC4_40_MD5
TLS_KRB5_EXPORT_WITH_RC4_40_SHA
TLS_KRB5_WITH_3DES_EDE_CBC_MD5
TLS_KRB5_WITH_3DES_EDE_CBC_SHA
TLS_KRB5_WITH_DES_CBC_MD5
TLS_KRB5_WITH_DES_CBC_SHA
TLS_KRB5_WITH_RC4_128_MD5
TLS_KRB5_WITH_RC4_128_SHA
*   TLS_RSA_WITH_AES_128_CBC_SHA
*   TLS_RSA_WITH_AES_128_CBC_SHA256
*   TLS_RSA_WITH_AES_256_CBC_SHA
*   TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_NULL_SHA256

Note the complete lack of ECDH or ECDHE cipher suites. Now again with
Java 8:

$ java8 -showversion -classpath libs/chadis-tools-1.55.jar
com.chadis.tools.security.SSLInfo
openjdk version "1.8.0_101"
OpenJDK Runtime Environment (build 1.8.0_101-b13)
OpenJDK Server VM (build 25.101-b13, mixed mode)

Supported SSL Protocols:
  TLS (SunJSSE)
  TLSv1 (SunJSSE)
  TLSv1.1 (SunJSSE)
  TLSv1.2 (SunJSSE)
Default Cipher Name
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
*   SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_128_GCM_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA256

Re: Proxy Apache https to Tomcat http

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ted,

On 10/5/16 3:42 PM, TED SPRADLEY wrote:
> Tomcat 7.0.68 Apache 2.4.6 CentOS  7.2.1511

Thanks.

> Problem: A Tomcat application at context "/mycontext" on port 8081
> running through Apache proxy renders as expected when using 
> http://example.com/mycontext but https://example.com/mycontext call
> renders "The requested URL /mycontext/ was not found on this
> server."
> 
> Question: Do I have a Tomcat Connector configuration problem? Or an
> Apache proxy configuration problem? Or an Apache ssl.conf problem?
> 
> Note: the CA issued certificate appears to be properly installed as
> evidence by the lock icon in the url bar displaying "Verified by Š
> " when doing a mouseover.
> 
> Files: Httpd.conf -  ServerName www.example.com 
> ServerAlias *.example.com ProxyRequests off ProxyPass
> /mycontext  http://example.com:8081/mycontext ProxyPassReverse
> /mycontext  http://example.com:8081/mycontext  
>  ProxyRequests off ProxyPreserveHost on 
> SSLEngine on SSLCertificateFile /path/to/certs/ca.crt 
> SSLCertificateKeyFile /path/to/key/private/exampleDotCom.key 
> ServerName www.example.com ServerAlias *.example.com ProxyPass
> /mycontext http://example.com:8081/mycontext ProxyPassReverse
> /mycontext http://example.com:8081/mycontext 

On first inspection, that looks correct.

> Tomcat's server.xml Connector  protocol="HTTP/1.1" connectionTimeout="2" 
> proxyName="www.example.com" proxyPort="80" redirectPort="8443" 
> xpoweredBy="false" server="Apache TomEE" />

That also looks correct.

How have you deployed your actual application?

> Ssl.conf - SSLEngine on
> 
> SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA
> 
> SSLCertificateFile /path/to/certs/ca.crt
> 
> SSLCertificateKeyFile /path/to/key/private/exampleDotCom.key
> 
> SSLCACertificateFile /path/to/bundle/ca_bundle.crt

Is ssl.conf actually included anywhere?

You will probably also want to use the RemoteIPValve and possibly the
SSLValve as well. Have a look at Tomcat's proxy support valves here:

https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Proxies_Suppo
rt

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJX9V9AAAoJEBzwKT+lPKRYL4YP/0KGogACGY7Ul3K59sMky8mz
tKjFmBU+jLk6DgyvUv6wI5ZcCRLukZsN6vvDU2psiIpGruakQjLfDtiDyPKnBGb3
G6jmvdfCNPfp9eWRMAKvI90tEvZ10g8/Qbzfp7XZ8tAOuoFSkxyoVYRrZMCoLUYq
UPCVsJQxhu5yFqzDzAz1AJN26b25Q2+F1W8GznCWz3pjmBjI44Y+y3FwlBVeayGZ
QaXp+VCzsKw4RRlUy8uO6KH63GgLvNWFZM3gYE85231Eu9RhtQREZNQG/geufnSD
3fy6pSQ1GvP+o2giUEgS0ik3zYjzmomtGGpbDQH2wCMuXTMJbJBM4iQZnhZ6Wz1Z
oDY6BRHvq+sTiEyJ4Ln6sKFymKccg3XSkwZ5UWHR+WA9NabyyEb7Li3AFYkpsyjk
o93QgPNqbzVBEmbsQTlsb/pfPPc3KoeCDRm5SLtMmPn9zDWHg30q0MGYbz8U96r8
cojk8k634UQ+B2q36IZpcZh6Ah295bU+I73JUh6T9RF1EcN8PgqOcH4cC7S10fV+
fiFqdz8XmV372jiiY1jk2Ka6SdJiYUo/froCUHlaNIsThMZra+D6woK55PO0e1yF
0HCAMEGAH+bwhJB5UgUj/4rHdcVHO32GRuH0jKpUauhfBh6/k385C58iw4ONsxyG
Iwa3OPXi7GUSCrWJ0lxr
=m3nm
-END PGP SIGNATURE-

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

Proxy Apache https to Tomcat http

[TED SPRADLEY]

Tomcat 7.0.68
Apache 2.4.6
CentOS  7.2.1511

Problem: A Tomcat application at context "/mycontext" on port 8081 running
through Apache proxy renders as expected when using
http://example.com/mycontext but https://example.com/mycontext call renders
"The requested URL /mycontext/ was not found on this server."

Question: Do I have a Tomcat Connector configuration problem? Or an Apache
proxy configuration problem? Or an Apache ssl.conf problem?

Note: the CA issued certificate appears to be properly installed as evidence
by the lock icon in the url bar displaying "Verified by Š " when doing a
mouseover.

Files:
Httpd.conf -

  ServerName www.example.com
  ServerAlias *.example.com
  ProxyRequests off
  ProxyPass /mycontext  http://example.com:8081/mycontext
  ProxyPassReverse  /mycontext  http://example.com:8081/mycontext


  ProxyRequests off
  ProxyPreserveHost on
  SSLEngine on
  SSLCertificateFile /path/to/certs/ca.crt
  SSLCertificateKeyFile /path/to/key/private/exampleDotCom.key
  ServerName www.example.com
  ServerAlias *.example.com
  ProxyPass /mycontext http://example.com:8081/mycontext
  ProxyPassReverse /mycontext http://example.com:8081/mycontext

Tomcat's server.xml Connector
 
Ssl.conf -
SSLEngine on

SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA

SSLCertificateFile /path/to/certs/ca.crt

SSLCertificateKeyFile /path/to/key/private/exampleDotCom.key

SSLCACertificateFile /path/to/bundle/ca_bundle.crt



Thank you,

Ted S.

[OT] ECDHE cipher suites missing on Amazon Linux / OpenJDK 7 and 8 ??

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Apologies for off-topic post, but lots of folks here have lots of
different experiences and maybe someone has come across this.

I've got a few servers in Amazon EC2 running Amazon Linux. I'm using
the OpenJDK package, and I have versions 1.7.0 and 1.8.0 running
side-by-side:

$ java -version
java version "1.7.0_111"
OpenJDK Runtime Environment (amzn-2.6.7.2.68.amzn1-i386 u111-b01)
OpenJDK Client VM (build 24.111-b01, mixed mode, sharing)

$ java8 -version
openjdk version "1.8.0_101"
OpenJDK Runtime Environment (build 1.8.0_101-b13)
OpenJDK Server VM (build 25.101-b13, mixed mode)

For some reason, a whole slew of crypto support is flat-out /missing/
from those packages (java-1.7.0-openjdk and java-1.8.0-openjdk).
Here's what I get when I run my SSLInfo tool on the box:

$ java -showversion -classpath libs/chadis-tools-1.55.jar
com.chadis.tools.security.SSLInfo
java version "1.7.0_111"
OpenJDK Runtime Environment (amzn-2.6.7.2.68.amzn1-i386 u111-b01)
OpenJDK Client VM (build 24.111-b01, mixed mode, sharing)

Supported SSL Protocols:
  TLSv1 (SunJSSE)
  TLSv1.1 (SunJSSE)
  TLSv1.2 (SunJSSE)
Default Cipher Name
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
*   SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA256
*   TLS_EMPTY_RENEGOTIATION_INFO_SCSV
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
TLS_KRB5_EXPORT_WITH_RC4_40_MD5
TLS_KRB5_EXPORT_WITH_RC4_40_SHA
TLS_KRB5_WITH_3DES_EDE_CBC_MD5
TLS_KRB5_WITH_3DES_EDE_CBC_SHA
TLS_KRB5_WITH_DES_CBC_MD5
TLS_KRB5_WITH_DES_CBC_SHA
TLS_KRB5_WITH_RC4_128_MD5
TLS_KRB5_WITH_RC4_128_SHA
*   TLS_RSA_WITH_AES_128_CBC_SHA
*   TLS_RSA_WITH_AES_128_CBC_SHA256
*   TLS_RSA_WITH_AES_256_CBC_SHA
*   TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_NULL_SHA256

Note the complete lack of ECDH or ECDHE cipher suites. Now again with
Java 8:

$ java8 -showversion -classpath libs/chadis-tools-1.55.jar
com.chadis.tools.security.SSLInfo
openjdk version "1.8.0_101"
OpenJDK Runtime Environment (build 1.8.0_101-b13)
OpenJDK Server VM (build 25.101-b13, mixed mode)

Supported SSL Protocols:
  TLS (SunJSSE)
  TLSv1 (SunJSSE)
  TLSv1.1 (SunJSSE)
  TLSv1.2 (SunJSSE)
Default Cipher Name
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
*   SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA
*   TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
*   TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
*   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
*   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_DH_anon_WITH_AES_128_GCM_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA256
TLS_DH_anon_WITH_AES_256_GCM_SHA384
*   

Re: Performance Issue - Tomcat 8 - Java 8 Web app with client side applet

[tomcat]

On 05.10.2016 16:16, Boyle, James A wrote:

Hello,
I have a web application compiled under Java 1.8 running in a 
Tomcat 8 container on a Linux web server. The client side devices are Windows 7 
desktops with USB attached printers. The basic operation is a query to a SQL 
Server database for the relevant address and then to print the information on 
an attached printer (Zebra ZM400 or ZP505). The first time through the print 
control on the screen activates pretty quickly, but successive retrievals 
introduce a 10-15 second delay before the label can be printed. The application 
is deployed as a WAR file and the print applet is signed with SHA-2. The 
prevailing theory is that the applet is being downloaded for each label being 
printed and that this is introducing the performance delay we are seeing. Is 
there a way to properly cache the applet, so that it does not need to be 
downloaded to the client workstation each time? Any insight would be greatly 
appreciated. Thanks.



Hi.
From your description, this does not look at all like a Tomcat problem, or even really a 
webserver problem.

It looks more like an issue on the client side.
If the client is indeed downloading the same applet over and over, that can only be 
because it is issuing HTTP retrieval requests to the server over and over.
Why it would do that, is more a question of the content of the initial page, and how the 
browser reacts to it.
You should probably install (or use) some browser plugin, which lets you trace the 
conversation between browser and server. Maybe that would give you a better hint about why 
this is happening.

Most recent browsers have such a debugging tool already built-in.
If not, then it depends a bit on the browser. For IE for example, you could have a look at 
"Fiddler2".



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

Performance Issue - Tomcat 8 - Java 8 Web app with client side applet

[Boyle, James A]

Hello,
   I have a web application compiled under Java 1.8 running in a 
Tomcat 8 container on a Linux web server. The client side devices are Windows 7 
desktops with USB attached printers. The basic operation is a query to a SQL 
Server database for the relevant address and then to print the information on 
an attached printer (Zebra ZM400 or ZP505). The first time through the print 
control on the screen activates pretty quickly, but successive retrievals 
introduce a 10-15 second delay before the label can be printed. The application 
is deployed as a WAR file and the print applet is signed with SHA-2. The 
prevailing theory is that the applet is being downloaded for each label being 
printed and that this is introducing the performance delay we are seeing. Is 
there a way to properly cache the applet, so that it does not need to be 
downloaded to the client workstation each time? Any insight would be greatly 
appreciated. Thanks.

Jim

--
This message, and any attachments, is for the intended recipient(s) only, may 
contain information that is privileged, confidential and/or proprietary and 
subject to important terms and conditions available at 
http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended 
recipient, please delete this message.

AW: Tomcat 8 HTTPS issue with old browser

[Kreuser, Peter]

Objections Chris,

> André,
> 
> On 10/4/16 7:59 AM, André Warnier (tomcat) wrote:
> > On 04.10.2016 12:43, Garratt, Dave wrote:
> >> To elaborate, there is only this single application running on
> >> the server. All other web applications use Windows IIS.
> >>
> >> I have mentioned that the problem is down to the old software on
> >> the scanner but it’s a huge international organisation and making
> >> a upgrade to their entire line of devices is likely to take some
> >> time.
> >>
> >> However silly it may seem this is a “tick the box” exercise when
> >> it comes to security - HTTPS - yes/no.
> >>
> >> On the assumption that a weak encryption is better than none then
> >> I can’t really argue with the customer.
> >
> > Maybe you cannot argue with the customer, that is for your
> > commercial environment to decide.  But on the professional ethics
> > side of thing, I would disagree with you on the previous item.  A
> > weak encryption can be worse than none, because it gives a false
> > sense of security. It may lead the customer to think that he is
> > protected, when in reality he is not. And it may be your duty as a
> > technical adviser, to point this out.
> 
> +1
> 
> Weak encryption is *worse* than no encryption IMO. You can argue about
> the definition of "weak", of course.
> 
> SSLv2 is definitely weak. A NULL symmetric cipher is definitely weak.
> Is RSA key negotiation weak? I think reasonable people can disagree
> over that, but I won't deploy it on any production machine unless
> there are no alternatives.
> 
> Since this is a barcode reader, it's unlikely that there are any
> problems with *confidentiality* of the data being transmitted. If you
> have to login to a "secure" server before reading barcodes, then you
> may have to consider the secrecy of the credentials for authentication
> even when the majority of the traffic will be non-private.
> 
> Assuming the confidentiality isn't a problem, then the only reasons to
> use encryption are authentication (of the server by the client) and
> integrity (to prove that nobody has meddled with the message).
> 
> If RSA authentication is good enough (and for most people, it is) and
> there are no issues with the authentication protocol (none that I can
> think of off the top of my head), then the differences between e.g.
> SSLv3 and TLSv1.2 are not that great.
> 
> That's a lot of "ifs".
> 
> It's also possible to use RSA authentication in a weak way. For some
> reason, Microsoft servers seem to be plagued by these issues in
> particular. 1024-bit RSA keys (and thus the certificates produced with
> them) have been deemed insecure for quite some time and I won't
> personally use a 2048-bit key for anything anymore. If the MC9090
> can't support keys of a certain length (I know of no SSL
> implementation that complains about "large" RSA keys) then you may not
> be able to get authentication (that the server is trusted by the
> client, that is) that is trustworthy.
> 
> If you are covered by PCI-DSS then you MUST NOT use anything less than
> TLSv1.1 by ... wow, it's still 2 years away. [0] At least NIST
> deprecated the use of TLSv1 and earlier effective *immediately*. Of
> course, it just says "you shouldn't use these", it doesn't say you
> MUST NOT use these. Oh, well. At least Google has the temerity to
> force changes on the Internet even if standards bodies won't keep
> pace. It doesn't matter if it's not a regulatory requirement if none
> of your users will visit your site unless you get serious about security
> .
> 
> Just some food for thought.
> 
> -chris
> 
> [0] Nice job, PCI-DSS... you were going to drive the industry forward
> until the industry cried like a bunch of babies about how they had
> large investments in crappy products and they didn't want to pay
> actual money to upgrade them. Better to swap fictional assets at
> ever-increasing margins pretending to make money to drive the stock
> price up. Heaven forbid you actually do something to protect
> yourselves, your shareholders, and your customers. 
>

PCI requires you to use TLS > 1.0 for new implementations starting last year 
with PCI 3.0.
So if you add TLS because of PCI now (well too late IMO), you MUST NOT use 
TLS1.0 anymore .

I do agree with you on the weakening of the requirements in 3.1 and 3.2, but of 
course there are also customers out there with devices that do not support 
TLS1.2. So if you want to be customer friendly and not block them before you 
even can get a message across, you may be content that the final call is only 
in 2018.

My 2cts

Peter


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