My initial problem was that when I was using IncludeCipherSuites option in jetty configuration file, only TLS 1.2 was being supported. Please see below post for details:
Jetty IncludeCipherSuites enables only TLS 1.2
Based on the comments it appeared that if I don't provide ExcludeCipherSuites in my jetty configuration file, jetty default exclude cipher list is being used and many ciphers which I explicitly enabled by IncludeCipherSuites option were being excluded (if they are in jetty default exclude list).
Just adding an empty ExcludeCiphersSuites tag together with IncludeCipherSuites tag in the same configuration file solved the problem. By saying empty I mean I didn't add any ciphers to exclude, I just added ExcludeCiphersSuites tag with empty list of ciphers:
<Set name="ExcludeCipherSuites">
<Array type="String">
</Array>
</Set>
My understanding is that previously (with only IncludeCipherSuites option) some of the the ciphers which I was including was being excluded by jetty default exclude list. However adding ExcludeCiphersSuites option with empty list forces to overwrite jetty's default exclude list with an empty list, so nothing is being excluded from my list of include ciphers. Can you please confirm that my understanding is correct?
Also based on all the above findings say jetty has the below default configuration for ciphers:
Jetty default exclude ciphers: CIPHER1, CIPHER2
Jetty default include ciphers: CIPHER3, CIPHER4
I want to configure my jetty to support CIPHER1 and CIPHER5 ONLY. Is the below the correct configuration I should use?
<Set name="ExcludeCipherSuites">
<Array type="String">
</Array>
</Set>
<Set name="IncludeCipherSuites">
<Array type="String">
<Item>CIPHER1</Item>
<Item>CIPHER2</Item>
</Array>
</Set>
Will this overwrite all jetty defaults and force jetty to support CIPHER1 and CIPHER2 and nothing else?
Jetty does not disable the protocols TLS/1.0 or TLS/1.1.
The configuration of protocols, ciphers, keystores, truststores, etc is all controlled by the SslContextFactory
The SslContextFactory has the ability to disable protocols, using the Include/Exclude of Protocols using configurations like addExcludeProtocols()
Note that Jetty does not include TLS/1.0 or TLS/1.1 in its default exclusions.
As of Jetty 9.3.13.v20161014 the default exclusion of protocols is as follows:
addExcludeProtocols("SSL", "SSLv2", "SSLv2Hello", "SSLv3");
Since you seem to be asking specifically about Cipher Suites, know that the Jetty 9.3.13.v20161014 default exclusions for Cipher suites is as follows:
setExcludeCipherSuites("^.*_(MD5|SHA|SHA1)$");
This happens to be the same set of cipher suites that were declared vulnerable back in 2008, and will cease to be used on Chrome and Firefox clients on Jan 1, 2017. This kill switch for MD5/SHA/SHA1 is present in all versions of Chrome and Firefox released in the last few (5-ish?) years.
Note also that Java itself disables various protocols and cipher suite algorithms.
$ grep -E "^jdk.*disabled" $JAVA_HOME/jre/lib/security/java.security
jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
Related
I have a simple xml context to display static files. The server loads fine and the page to show files loads as expected. The issue is that file with permission 000 are still showing in the list. If I click on one of the files I get a java stack trace error saying that jetty does not have permission to read the file (because it doesnt).
Does anyone know how to get these files with no read permission to not show up?
I am using jetty distribution version 9.4.34.v20201102. I run jetty as a service and have JETTY_USER set in /etc/default/jetty.
Here is my simple context in JETTY_BASE/webapps/static.xml
<Configure class="org.eclipse.jetty.server.handler.ContextHandler">
<Set name="contextPath">/</Set>
<Set name="handler">
<New class="org.eclipse.jetty.server.handler.ResourceHandler">
<Set name="resourceBase">/mshr/test/</Set>
<Set name="directoriesListed">true</Set>
</New>
</Set>
</Configure>
This is not supported by the Jetty ResourceHandler, the ResourceService, or the DefaultServlet.
Asking about file permissions during file listing is actually quite an expensive thing to do (depending on the file system).
That's why Jetty doesn't do that.
If you feel otherwise, file a request at https://github.com/eclipse/jetty.project/issues
For backwards compatibility reasons I need a Geode Jetty server to use TLSv1 and not 1.1 or 1.2
With ssl-enabled-components=web and ssl-protocols=TLSv1.0 set in gemfire.properties then when I start the Geode and check the HTTPS connectivity with SSL Labs then I get a TLS result:
I am looking for the TLS 1.1 and TLS 1.0 checks to also say Yes not No
The Geode SSL docs say Make sure your Java installation includes the JSSE API and familiarize yourself with its use.
The JSSE is about the java.security config in the JRE/lib/security directory. I set this not to disable any security algorithms and restarted Geode but the results are the same. TLS 1.1 and 1.0 are failing the SSL Labs test above.
Is there a way to force Geode to start with https.protocols=TLSv1 ?
When I try to start a locator with that using --J=-XX:https.protocols=TLSv1 then I get
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Unrecognized VM option 'https.protocols=TLSv1'
There is no separate Jetty config I can find...
Update --J=-Dhttps.protocols=TLSv1 is the correct setting to assign TLS protocols to the JVM and that works on starting Geode locator and server.
Update When I set java.security setting jdk.tls.disabledAlgorithms=TLSv1.1, TLSv1.2 like the opposite of this then it's not possible to communicate via HTTPS with the Jetty server at all. This makes me think the Geode / Jetty ssl-protocols=TLSv1.0 setting does not apply either?
The Jetty config says TLS v1.0, v1.1 and SSL v3 are no longer supported by default. If your Jetty implementation requires these protocols for legacy support, they can be enabled manually.
Is there a way to configure Jetty with Geode?
I don't believe you can currently achieve this. Mainly because of how Jetty is being configured internally. Jetty maintains a list of excluded ciphers defined by the regex ^.*_(MD5|SHA|SHA1)$. Unfortunately, it seems that this list trumps any ciphers which may be added as 'included'. Here's a very simple Jetty example that I used for testing: https://gist.github.com/jdeppe-pivotal/c0c6e7de4282bc077357749fc91bc44f. Jetty will produce a nice dump of the ciphers and protocols it is using when you run this.
As it stands, you can perform a successful request with the following curl: curl -k -v --tlsv1.2 https://localhost:8081/. Now, if you try that with tlsv1.0 it will fail because the necessary cipher suites are all disabled. However, if you uncomment the line: sslContextFactory.setExcludeCipherSuites() then things should start working. What this does is to remove all the current excluded ciphers (and allow them to be used). Unfortunately if you only try and add ciphers (without also excluding everything) things still don't work. Note that by doing this, Jetty is still configured for TLSv1.2 (and 1.1 and 1.0) but the client can use a lower protocol version.
The bottom line is that Geode does not explicitly exclude any ciphers from Jetty. Thus if you're hoping to add the necessary ciphers, they will most likely not be effective. I've opened a bug for this: https://issues.apache.org/jira/browse/GEODE-3891
How do i configure Railo on Jelastic (PAAS) to work with multiple domains using Jetty?
I found the configuration for Railo using Tomcat, but I would like to use Jetty because of the memory requirements
Thanks
In Jelastic there are at least 2 possible ways of binding your domain name.
Actually you can bind your domain by deploying your application to a specified context ROOT via Jelastic dashboard. Here is an article which explains how to manage it: http://jelastic.com/docs/custom-domains
The second way is to set DNS A Record. The given article explicitly shows how to do it: http://jelastic.com/docs/A-Records-domain-names
I am not sure on the Jelastic specific side, but with Jetty you can create an XML file in the contexts folder, and it should look something like this:
contexts/Localhost.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
<Set name="contextPath">/</Set>
<Set name="resourceBase"><SystemProperty name="jetty.home" default="."/>/webapps/railo/</Set>
<Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set>
<!-- virtual hosts -->
<Set name="virtualHosts">
<Array type="String">
<Item>localhost</Item>
<Item>127.0.0.1</Item>
</Array>
</Set>
</Configure>
You can then create more files in there for each domain, making sure you add/edit the entries for the resourceBase (your file webroot) and in the Item for the virtual host.
I am not sure how Jelastic handles this stuff with Jetty specifically, but if you can edit the files you should be cool.
Jetty allows headers to be set using the jetty-rewrite functionality, but it doesn't appear to be very smart, and only accepts a fixed string.
How do I tell Jetty to send an "expires in 8 hours" header?
With Apache .htaccess and mod_expires you can do "access plus 8 hours" but of course Jetty doesn't understand .htaccess files, nor can I find any info on a similar construct in jetty-rewrite.xml
<Call name="addRule">
<Arg>
<New class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
<Set name="pattern">*.png</Set>
<Set name="name">Expires</Set>
<Set name="value">access plus 8 hours</Set>
</New>
</Arg>
</Call>
That just sends the literal text "access plus 1 day" back, which is of course ignored by the client.
Could/should this be done with a servlet filter? Jetty has a Gzip filter but doesn't appear to offer something similar for dynamically setting headers.
That could be a nice feature..
Open an enhancement for it at bugs.eclipse.org under RT/Jetty. Patches are welcome, either attached to the bug or pushed into our gerrit instance.
That being said...the jetty xml is really an xml layer over java so I suspect you could actually so this in java if you can find the APi for it. I think there is a joda time library that has a method where you could wire up something that would call new DateTime().plusHours(8) to populate that value.
Probably better to add it as a feature though.
I am trying to secure communications via SSL/TLS for one of our Web Service using CXF 2.2.5.
I am wondering how to update client and server Spring configuration file to activate this feature.
I found some information on CXF's website (CXF Wiki) for the client configuration, here is the given example:
<http:conduit name="{http://apache.org/hello_world}HelloWorld.http-conduit">
<http:tlsClientParameters>
<sec:keyManagers keyPassword="password">
<sec:keyStore type="JKS" password="password"
file="src/test/java/org/apache/cxf/systest/http/resources/Morpit.jks"/>
</sec:keyManagers>
<sec:trustManagers>
<sec:keyStore type="JKS" password="password"
file="src/test/java/org/apache/cxf/systest/http/resources/Truststore.jks"/>
</sec:trustManagers>
<sec:cipherSuitesFilter>
<!-- these filters ensure that a ciphersuite with
export-suitable or null encryption is used,
but exclude anonymous Diffie-Hellman key change as
this is vulnerable to man-in-the-middle attacks -->
<sec:include>.*_EXPORT_.*</sec:include>
<sec:include>.*_EXPORT1024_.*</sec:include>
<sec:include>.*_WITH_DES_.*</sec:include>
<sec:include>.*_WITH_NULL_.*</sec:include>
<sec:exclude>.*_DH_anon_.*</sec:exclude>
</sec:cipherSuitesFilter>
</http:tlsClientParameters>
<http:authorization>
<sec:UserName>Betty</sec:UserName>
<sec:Password>password</sec:Password>
</http:authorization>
<http:client AutoRedirect="true" Connection="Keep-Alive"/>
</http:conduit>
Concerning this configuration, the
Concerning the server side configuration I am unable to launch the server properly, here is the configuration I have:
<http:destination name="{urn:ihe:iti:xds-b:2007}DocumentRepository_Port_Soap12.http-destination">
</http:destination>
<httpj:engine-factory>
<httpj:engine port="9043">
<httpj:tlsServerParameters>
<sec:keyManagers keyPassword="changeit">
<sec:keyStore type="JKS" password="changeit" file="security/keystore.jks" />
</sec:keyManagers>
<sec:trustManagers>
<sec:keyStore type="JKS" password="changeit" file="security/cacerts.jks" />
</sec:trustManagers>
<sec:cipherSuitesFilter>
<!--
these filters ensure that a ciphersuite with export-suitable or null encryption is used, but exclude
anonymous Diffie-Hellman key change as this is vulnerable to man-in-the-middle attacks
-->
<sec:include>.*_EXPORT_.*</sec:include>
<sec:include>.*_EXPORT1024_.*</sec:include>
<sec:include>.*_WITH_DES_.*</sec:include>
<sec:include>.*_WITH_NULL_.*</sec:include>
<sec:exclude>.*_DH_anon_.*</sec:exclude>
</sec:cipherSuitesFilter>
<sec:clientAuthentication want="true" required="true" />
</httpj:tlsServerParameters>
</httpj:engine>
</httpj:engine-factory>
But when I run my application server (JOnas) with this configuration I have the following error message:
Line 20 in XML document from ServletContext resource [/WEB-INF/beans.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'httpj:engine-factory'.
Do you guys know how to solve this issue?
Thanks in advance,
It sounds like you are missing a namespace declaration or you have fat-fingered your XML. This is likely more of a Spring related issue than a CXF issue.
Check that the following items appear on your beans element where you declare httj:engine-factory:
<beans
...
xmlns:httpj="http://cxf.apache.org/transports/http-jetty/configuration"
...
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://cxf.apache.org/transports/http-jetty/configuration http://cxf.apache.org/schemas/configuration/http-jetty.xsd
...">
<import resource="classpath:META-INF/cxf/cxf-extension-http.xml" />
<import resource="classpath:META-INF/cxf/cxf-extension-http-jetty.xml" />
Check that the CXF Jetty Transport JAR is in your classpath at runtime.
If you add the declaration and the schema location to your context file in your IDE (at least in Eclipse with the Spring plug-ins and IDEA) you should get schema validation right in your IDE so you can easily find any mistakes you make and take advantage of auto-completion.