draeath
commented
5 years ago For completeness, this is the cas-redirect.war code. It does nothing fancy whatsoever. This problem exists even if this is the only context, and it's put down as ROOT.war.
Done this to rule out the war files I'm trying to use as the source of this trouble.
pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>REDACTED</groupId>
<artifactId>cas-redirect</artifactId>
<version>1.0</version>
<packaging>war</packaging>
<name>cas-redirect</name>
<url>REDACTED</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<isExecutable>false</isExecutable>
</properties>
<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.1.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<finalName>cas-redirect</finalName>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.6</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>src/main/java/REDACTED/cas/Redirect.java:
package REDACTED.cas;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.util.logging.Logger;
import java.util.logging.Level;
public class Redirect extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
final Logger logger = Logger.getLogger(Redirect.class.getName());
String forwardedForHeader = request.getHeader("X-FORWARDED-FOR");
String clientAddress = (forwardedForHeader != null) ? request.getRemoteAddr() + " (X-FORWARDED-FOR: " + forwardedForHeader + ")" : request.getRemoteAddr();
logger.log(Level.WARNING,"redirecting out-of-context request from " + clientAddress + " for " + request.getRequestURL());
StringBuffer replyURI = new StringBuffer("/cas");
StringBuffer requestedURI = new StringBuffer(request.getRequestURI());
String[] requestedURIparts = requestedURI.toString().split("/");
boolean hasQueryString = new Boolean(request.getQueryString() != null);
if (requestedURIparts.length > 2) {
for (int i = 2; i < requestedURIparts.length; i++) {
replyURI.append("/" + requestedURIparts[i]);
}
}
if (hasQueryString) {
replyURI.append('?' + request.getQueryString());
}
response.sendRedirect(replyURI.toString());
}
}src/main/webapp/WEB-INF/web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" metadata-complete="true" version="3.0">
<display-name>CAS Redirect</display-name>
<servlet>
<servlet-name>redirect</servlet-name>
<servlet-class>REDACTED.cas.Redirect</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>redirect</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
joakime
Specific image ID:
1dc9280cc083Jetty starts, and the contexts appear to come up. However, all attempts to access them via SSL fail as follows. Yes, the port is exposed and not firewalled etc - this happens even via localhost.
EDIT: confirmed.
8u181-b13-1~deb9u1works,8u181-b13-2~deb9u1BREAKS,8u212-b01-1~deb9u1works again (caveat: have to add an alpn-impl pointing at alpn-boot-8.1.13.v20181017)Note if I leave the ciphers parameter off, the defaults fail in the same way.
Packet capture shows:
There is no log, STDOUT, or STDERR emissions from Jetty when this occurs.
Digging around, I discovered the following. I have an older build of this software that's working fine. I performed a
docker container exportof both the old build and the new one (which fails), and did a recursive diff between. Ignoring binary differences, I found the following differences, and only the following differences, presumably from upstreamopenjdk:8-jre7.52.1-5+deb9u6to7.52.1-5+deb9u78u181-b13-1~deb9u1to8u181-b13-2~deb9u1Debian package changelogs for these show the curl change seems unrelated:
However the java changelog seems particularly relevant:
Specifically this update touches several areas around TLS/SSL.
Now, for some of my local info for context.
Dockerfile:
Referenced ssl.ini content:
https://apereo.github.io/cas/5.3.x/index.htmlbut this issue happens even if this context is omittedkeystore is valid with one private key and public cert pair: