Re: Mutual SSL client certificate validation(Key Usage and Extended Key Usage) in tomcat server

[Mark Thomas]

On 05/02/2018 02:14, Indunil Rathnayake wrote:

Hi,

On 2 February 2018 at 19:55, Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 2/2/18 5:35 AM, Mark Thomas wrote:

On 02/02/18 04:06, Christopher Schultz wrote:




It seems reasonable for Tomcat to verify that any "critical"
key-use extensions are respected, and perhaps even some
non-critical ones.


I'd assume that JSSE / OpenSSl do this automatically. Is there any
evidence that they do not?


Sorry, I meant to say that Tomcat should probably perform those checks
if the underlying TLS handler is not already doing them, or instruct
the underlying handler to perform those checks if they are not already
being done and can be done during the handshake.



Thanks.. Appreciate if you can share some reference for how we can enable
this validation through a tomcat handler.


I'll repeat. Is there any evidence that this is not already being 
performed in JSSE / OpenSSL by default?


Mark


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

Re: jsessionid path parameter: Is this compliant with the Servlet 3.0 spec?

[Dave Glasser]

 Thanks, that is pretty clear and unambiguous, as is "The name of
the parameter must be jsessionid." When the spec is in conflict with itself, 
I'm happy to consider Tomcat the reference implementation.
The reason a session cookie name had to be specified in the first place was 
because we initially had just this:

  
    true
  


Because we wanted the httpOnly flag. But that broke Weblogic, because Weblogic 
interpreted that to mean that we wanted to the session cookie name to be null, 
rather than the default, and it started throwing:

java.lang.IllegalArgumentException: Cookie name must not benull or empty

   at javax.servlet.http.Cookie.(Cookie.java:172)

   
atweblogic.servlet.internal.ServletResponseImpl.setSessionCookie(ServletResponseImpl.java:1446)

So we had to specify a cookie name, and thought JSESSIONID was the obvious 
choice. Little did we know. And the problem it caused with the desktop app 
launching the browser was discovered long enough afterward that it took some 
time to figure out the connection.

On Sunday, February 4, 2018, 5:35:04 PM EST, Mark Thomas  
wrote:  

No. This is not a bug. See the final paragraph of section 7.1.1

"If a web application configures a custom name for its session tracking
cookies, the same custom name will also be used as the name of the URI
parameter if the session id is encoded in the URL (provided that URL
rewriting has been enabled)."

Specifying a custom name that is the same as the default is an arguable
edge case but I'm going to lean towards the current Tomcat implementation.

Regarding the Javadoc, it probably was a copy and paste and should be
corrected. I'll get that done shortly.

Mark

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

  

Re: Mutual SSL client certificate validation(Key Usage and Extended Key Usage) in tomcat server

[Indunil Rathnayake]

Hi,

On 2 February 2018 at 19:55, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark,
>
> On 2/2/18 5:35 AM, Mark Thomas wrote:
> > On 02/02/18 04:06, Christopher Schultz wrote:
> >
> > 
> >
> >> It seems reasonable for Tomcat to verify that any "critical"
> >> key-use extensions are respected, and perhaps even some
> >> non-critical ones.
> >
> > I'd assume that JSSE / OpenSSl do this automatically. Is there any
> > evidence that they do not?
>
> Sorry, I meant to say that Tomcat should probably perform those checks
> if the underlying TLS handler is not already doing them, or instruct
> the underlying handler to perform those checks if they are not already
> being done and can be done during the handshake.
>

Thanks.. Appreciate if you can share some reference for how we can enable
this validation through a tomcat handler.


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlp0dNodHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFioMQ/8CjEoj/JLUblsMIOF
> m/tQ3UuuNz1s1vxfpHUWCI1BRIGmu4fGYnKmjaFuGn2iHVpt7lMjOreXkHNtkVdP
> g7oPbdihGkltIOrj4ayiZXNMH40fMRRHNqQEITKMR+u9f0smqzJB3A2YYcO9qvtH
> MDv/Vg1c2f5btWDfXj9FV5rwbtrMbJSFrwDg0mOTOEoZMjtr3FCxbT8XfMseGE85
> a7WCEljodU64ef5F0tbsj4KQqNFcVkkpI8YpGni1y9suDFyeN2JXeVJUJRK2f28A
> 55HIQvhVvWU3d+c2ZfQQJiY1XJ7Feg+54rczXXusfIxMd/zQxvptdMlzRjkss5Rg
> 7MzrpO3NDPmDadAeTw0pDAAhUzWVn/BlGlb7hioXkU/lJR/PzN03DbiVdC6HBquj
> 0f0rV53MhS28SmhU1GCLex1kyDqlRfcqpd0QD+Yyi/WgcnVR4lr60brdu8WquvuQ
> qT5jtT/tSZHImMGGGnVxE0Fg0wZaSdBf9tA9NqNAYUXsoMituRTeDQoL9DeIPs0F
> QDnURxtOTfkhmtq/wYeZSqzoPZGdSyfTT6quOugVeECrLkT7lZQHetGLIwlNVuRY
> gP17H521N46dysVe/Qec1o+7FTJsJ7eQ/nEtJVnCI8PPJBT3XITB+LDaHEc5XNSH
> BUB6HOt4pNpncpdWSO8o1HgDNfc=
> =EEgh
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 

*Indunil Rathnayake *

*Faculty of Information Technology*

*University of Moratuwa.*

Re: jsessionid path parameter: Is this compliant with the Servlet 3.0 spec?

[Mark Thomas]

On 03/02/18 21:55, Dave Glasser wrote:
> This text is based on a stackoverflow question I posted earlier today:
> https://stackoverflow.com/questions/48600576/jsessionid-as-path-parameter-not-working-in-tomcat/48602272
> 
> 
> I'm using Tomcat 7.0.84, and my web app uses the Servlet 3.0 deployment 
> descriptor. The web.xml file contains this:
> 
> 
>   
>     JSESSIONID
>     false
>   
>   URL
>   COOKIE
> 
> 
> I have a desktop application that logs into the web app and establishes a 
> session. In response to a user action, it invokes a URL in a browser. Since I 
> want the browser to be logged in with the same session, I append the 
> jsessionid path parameter like this:
> 
> http://server/contextroot/path/;jsessionid=8BDF744802E7850D5AA4AB6535163504
> 
> I close my browser completely so when the URL is spawned, no previous session 
> cookies will be sent. (My default browser is chrome, and I verify this is the 
> case.)
> 
> I also verify in code that the URL tracking mode is enabled, by logging the 
> return value of ServletContext.getEffectiveSessionTrackingModes.
> 
> What I'm expecting is the browser request to automatically get the session 
> indicated by the ;jsessionid parameter, but it is not happening. Each time 
> Tomcat includes a new session cookie in its response.
> What DOES work, and what I suspect does not comply with the servlet 3.0 spec, 
> is either of these workarounds:
> 1. In web.xml, change the name of the session cookie from JSESSIONID to 
> jsessionid2. In the URL, change the name of the path parameter from 
> jsessionid to JSESSIONID.
> 
> Section 7.1.3 of the Servlet 3.0 spec contains this text:
>   The session ID must be encoded as a path parameter in the URL string. The 
> name of
>   the parameter must be jsessionid. Here is an example of a URL containing 
> encoded
>   path information:
> 
>   http://www.myserver.com/catalog/index.html;jsessionid=1234
> 
> It does not provide at all for configuring a name for the path parameter used 
> to pass in the session ID. It says explicitly, "The name of the parameter 
> must be jsessionid."
> But in org/apache/catalina/util/SessionConfig.java, this code is used to get 
> the name of the session parameter:
>     private static final String DEFAULT_SESSION_PARAMETER_NAME = "jsessionid";
> ...
> 
>     /**
>  * Determine the name to use for the session cookie for the provided
>  * context.
>  * @param context
>  */
>     public static String getSessionUriParamName(Context context) {
> 
>     String result = getConfiguredSessionCookieName(context);
> 
>     if (result == null) {
>     result = DEFAULT_SESSION_PARAMETER_NAME;
>     }
> 
>     return result;
>     }
> 
> 
> I included the Javadoc because it seems to indicate this method was 
> originally copy/pasted and then modified. The logic is, if there is a name 
> configured for the session cookie, use the same name for the session path 
> parameter, otherwise use jsessionid.
> 
> So, can anyone tell me if my suspicion that this is non-compliant (and hence, 
> a bug) correct?

No. This is not a bug. See the final paragraph of section 7.1.1

"If a web application configures a custom name for its session tracking
cookies, the same custom name will also be used as the name of the URI
parameter if the session id is encoded in the URL (provided that URL
rewriting has been enabled)."

Specifying a custom name that is the same as the default is an arguable
edge case but I'm going to lean towards the current Tomcat implementation.

Regarding the Javadoc, it probably was a copy and paste and should be
corrected. I'll get that done shortly.

Mark

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