PortResolverImpl will resolve to 8080 if request port is 8443

[nucatus]

Summary

The PortResolverImpl.java will resolve to 8080 in case you run http on 8443, thus resulting in wrong behavior.

Since this implementation is a specific fix for a IE bug, I guess all the logic should be conditioned by the presence of the IE user-agent header. Otherwise, no translation is necessary.

Actual Behavior

As described above.

Expected Behavior

The port should remain the same, even if you run http over 8443 (8443 is not a standard port for https in the first place, maybe just a convention, but not explicitly defined as such)

Configuration

Standard Spring security implementation

Version

4.1.3

[hauntingEcho]

This issue will also happen on 5.1, and will also happen in reverse (setting HTTPS to port 8080 will resolve to 8443)

see also: spring-projects/spring-boot#6140

assuming the behavior has to remain the same, a log warning/error would be very much appreciated when this workaround is encountered.

[rwinch]

The problem is if we log a warning and the user is running http on port 8443, then we are logging an invalid warning. Do you have a proposal that does not cause invalid logging to happen? Otherwise, this is really just a matter of the user needing to configure things correctly.

[hauntingEcho]

by my understanding, running HTTPS on 8080 (or HTTP on 8443, for @nucatus ) is not currently possible. I'll admit to being relatively new to Spring Security, though. To clarify a bit, the configuration that led me here was:

application-local.properties:

# SSL setup
server.contextPath = /
server.port = 8080
server.ssl.enabled = true
server.ssl.keyStoreType = JKS
server.ssl.keyAlias = local.test.key
server.ssl.key-store-password = changeit
server.ssl.key-password = changeit

WebSecurityConfigurerAdapter extension with @EnableGlobalMethodSecurity(prePostEnabled=true):

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    //use this if you need to use bad certs for some reason: HttpsURLConnection.setDefaultHostnameVerifier ((hostname, session) -> true);
    http
        .logout().logoutUrl("/logout").logoutSuccessUrl(logoutSuccessUrl).permitAll()
        .and()
        .authorizeRequests()
        .anyRequest()
        .authenticated()
        .and()
        .oauth2Login().loginPage(loginPage) // loginPage = "/oauth2/authorization/wso2", wso2 provider configured elsewhere
        .userInfoEndpoint().oidcUserService(userService);
  }

which caused the loginPage redirection to go to port 8443. Changing to server.port=8081 resolved the issue.

[rwinch]

Did you try providing your own mapping. For example:

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        // ....
        .portMapper()
            // the HTTP port of 9443 maps to the HTTPS port of 8080
            .http(9443).mapsTo(8080)
            // the HTTP port of 80 maps to the HTTPS port of 443
            .http(80).mapsTo(443);
}

[hauntingEcho]

to clarify a bit - in this case we would need to add guardrails like this for the person provisioning the server:

//given `server` is injected already
HttpSecurity httpSecurity = http.// existing setup
if (server.ssl.enabled && 80 == server.port % 1000) {
  httpSecurity.portMapper().http(server.port).mapsTo(server.port - 80 + 443);
  log.warn("using ports ending with 80 not recommended with https");
} else if (!server.ssl.enabled && 443 == server.port % 1000) {
  httpSecurity.portMapper().http(server.port).mapsTo(server.port - 443 + 80);
  log.warn("using ports ending with 443 not recommended without https");
}

is that correct?

[rwinch]

Rather than warning you would just look up the ports and map them:

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        // ....
        .portMapper()
            // the HTTP port of 9443 maps to the HTTPS port of 8080
            .http(httpPort).mapsTo(httpsPort)
            // the HTTP port of 80 maps to the HTTPS port of 443
            .http(80).mapsTo(443);
}

[hauntingEcho]

however, our user in this case did not specify that we could use port 8443, and we'd like to minimize impact to ports other than the one the user has specified. Admittedly my example messages could use some improvement (mentioning which additional port has been claimed and why)

[rwinch]

Closing this since Spring Security has no idea what your HTTP Port or HTTPS Ports are. Users must configure this themselves.