Win a copy of Microservices in Action this week in the Web Services forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

Tomcat HTTPS Redirect Issue  RSS feed

 
Bartender
Posts: 9550
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm attempting to secure parts of an application with HTTPS.  I configured the application's web.xml with a <security-constraint>.  Whenever I attempt to access a secured resource, I receive an error on the browser to the effect that "The page isn't redirecting properly".  If I try to access an unsecured resource, both HTTP and HTTPS work fine.
Tomcat is running behind a proxy (Blue Coat) which forwards the usual ports (80/443) to Tomcat's 8080/8443.  The following is the relevant section from my Tomcat's server.xml (the proxyName "example.org" is the "real" TLD on my server and I redacted the list of ciphers because it's huge).  Is there anything obvious I've done wrong?

 
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I prefer to use Apache with mod_proxy (or mod_jk) myself. In the case of Apache and Nginx, the decryption is actually handled by the front-end server, not by Tomcat, so port 8443 wouldn't be used. It's quite likely the same thing applies to you. Definitely if the BlueCoat server has an SSL cert installed instead of being a verbatim relay.
 
Joe Ess
Bartender
Posts: 9550
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are correct that the Blue Coat proxy is set up to handle the external SSL, however, when one hits a resource restricted by <security-constraint>, Tomcat that sends a redirect to use HTTPS, and I think that is where my problem lies.  For some reason (that I have probably configured), it is sending a URL that triggers another redirect and another and the browser gives up.
 
Tim Holloway
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Where is the proxy server forwarding SSL (port 443) traffic to? Is it going to 8080 or 8443? Because as far as I can see, you're expecting encrypted traffic on 8443, but if the proxy has already decrypted the request, it won't be in the expected format.

Actually, I'm surprised that it didn't whine about not having a keystore considering the other options.
 
Joe Ess
Bartender
Posts: 9550
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I believe if an HTTPS request goes to the proxy, it forwards it as HTTPS to the server (my proxy guy is out of the office.  I'll have to touch base with him).
As for the keystore, it has a reasonable default:

By default, the pathname is the file ".keystore" in the operating system home directory of the user that is running Tomcat

Tomcat Docs
 
Tim Holloway
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Joe Ess wrote:I believe if an HTTPS request goes to the proxy, it forwards it as HTTPS to the server



As I said, if the proxy port is configured as https, then what gets forwarded will have been decrypted already. The "http" and "https" protocols are not hard-wired into ports, they're configured as part of the server. The closest thing to hard-wiring there is is on the client side, where a url of "http://server" is assumed to be "http://server:80" and a url of "https://server" is assumed to be "https://server:443", which is why you always have to explicitly request 8080 and 8443 on direct-to-Tomcat URLs. But if I was sufficiently malicious, I could make my proxies serve https on port 80 and serve http on port 443 and you'd have to override the defaults in your client URL (e.g., https://server:80 [sic])

 
Tim Holloway
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Almost forgot. Knowing where the keystore is is one thing, but I would be seriously concerned if Tomcat knew the keystore password without one being coded in. That kind of thing ends up as major security exploits - for example, the infamous SQL Slammer.
 
Joe Ess
Bartender
Posts: 9550
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote: The "http" and "https" protocols are not hard-wired into ports, they're configured as part of the server.



I understand that.  I reviewed the proxy settings with our security guy.  As you say, both HTTP and HTTPS to the proxy are being forwarded to Tomcat's HTTP port.   I have another server running Weblogic and the proxy is set up to forward any HTTP requests to Weblogic's HTTP port and HTTPS to Weblogic's HTTPS port (insert saying about "assuming" here...).
I tried removing the HTTPS connector from my Tomcat configuration and the problem still remains.  Too many redirects.  
This may be a problem with Apache Roller (the application I'm trying to secure) or one of its dependencies.  A similar issue is on the mailing list from a previous version here

Tim Holloway wrote:I would be seriously concerned if Tomcat knew the keystore password without one being coded in



Agreed.  If I go back to using the HTTPS connector I'll change it.
 
Tim Holloway
Bartender
Posts: 19996
95
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You might find enlightenment by checking the logs. Your proxy server may have a forwarding long, Tomcat can log requests using a logging Valve, and some clients can report the client redirects in displays of their own. I think I've had to deal with something like what you're encountering, although in my case, it was usually an nginx forward to a back-end VM. And it can be annoying.
 
Greenhorn
Posts: 6
Chrome Fedora Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I might be wrong here, but it looks like you've created a redirect loop.

From what you've said, I believe the connection is getting routed like so:

  • Connection comes in on port 80
  • Proxy redirects it to 8080  
  • Tomcat redirects it to 443  
  • Proxy redirects it to 8080

  • ... and the loop repeats.

    Without seeing your proxy config I can't be sure, but it sounds like this is likely what is happening
     
    Joe Ess
    Bartender
    Posts: 9550
    12
    Linux Mac OS X Windows
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Welcome to the Ranch!

    Asher Max Schweigart wrote:I might be wrong here, but it looks like you've created a redirect loop.



    I concur.  I've put in requests to have changes made to the firewall and proxy to allow HTTPS requests to be forwarded to Tomcat's port 8443.
     
    Joe Ess
    Bartender
    Posts: 9550
    12
    Linux Mac OS X Windows
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I wanted to check back in and confirm that once we had SSL enabled from the proxy to Tomcat, this issue was resolved.  
    We had quite a bit of trouble getting Tomcat's Connector configured.  If I specify any security options like sslProtocol, sslEnabledProtocols or ciphers, the proxy would not connect.  If I do not specify those parameters, Bluecoat connects fine and selects the most secure options (i.e. using TLS v1.2 and a very secure cipher) even though those were the values for the options I specified earlier.  I don't think this matters, seeing as how it is Bluecoat that negotiates security with the browser, but just one more thing to add to the "not working as expected" list.
     
    It is sorta covered in the JavaRanch Style Guide.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!