Switching from https to http - this one again

[Brendan Healey]

You probably know the scenario by now - you're putting an application together (I'm using JSF 2.0
on a glassFish v3 stack) and the very first thing you've got to do is write some login code. Quickly
you realise that you don't want the login details sent in clear over the wire and decide that SSL
would be the sensible option.

It soon becomes apparent that you can setup a <transport-guarantee> set to CONFIDENTIAL that
makes the browser access the login page with the https:// prefix, and then you're stuck with it (SSL)
for evermore.

I really don't want to take the performance hit of using SSL except on a couple of pages. The content
is just not that sensitive.

I tried navigating away from the secure page using a <to-view-id> with a fully specified URL with a
http:// prefix but a '/' gets prefixed to the URL value and it doesn't work.

I've seen suggestions along the lines of writing phase listeners or custom view handlers but to be
honest I'd rather graduate to this level of complexity further down the line, not when I'm writing
screen number 1.

Why is this so hard to do? Can anyone suggest a simple solution to solve this problem? One option
I've considered is to ditch https:// and simply encypt the username/password with MessageDigest,
or just send everything over the wire in the clear!

Any help greatly appreciated.

Regards,
Brendan.

[Tim Holloway]

Brendan Healey wrote:You probably know the scenario by now - you're putting an application together (I'm using JSF 2.0
on a glassFish v3 stack) and the very first thing you've got to do is write some login code.

No it's not. In most cases, I don't write ANY login code, because J2EE comes with a perfectly good authentication and authorization system of its own, pre-debugged, vetted by security professionals, and ready to use. And, since it's an integral part of J2EE, it automatically handles switching to secure channels at need.

I've got a list that currently runs to about 13 items on why it's really, really bad to invent your own security system, and I may end up adding #14 if I see much more wrong with the project I recently acquired with Yet Another DIY security system (and one that's more secure than most, but not secure enough).

End of rant.

Actually, as far as I'm aware, just because you used one page with TLS doesn't mean the next page is required to be so as well. In fact, I'll assert it, since the "#14" case application I mentioned is ping-ponging between http and https like mad. The client in fact explicitly asked why most of the app was running on non-TLS protocols. And they didn't like it. And, once I realized the abuses it made possible (including charging people's credit card numbers in bulk), neither did I. I'll probably get paid to overhaul the whole security subsystem before much longer.

TLS isn't that painful. Hardware handles a lot of the overhead these days. Mixing TLS images/css and non-TLS forms under IEis painful, however. And once logged in, it's a fair bet that most of what gets access is going to be at least a little sensitive. But it it's not, simply send back a URL specifying the "http:" protocol for whatever operation you wish to be done next.

You can't return non-TLS output for a TLS request, because the request/response cycle is a unit and once it's been declared secure, it remains secure until it's done. But that doesn't mean that the next request is required to be TLS as well.

HTTP is not a connect-once-and-keep-talking protocol. Each request/response is an independent communication. The only reason that HTTP even remotely resembles a traditional client server operation is by generous use of various hacks such as the "keep-alive" connection features and the HttpSession object of J2EE.

[leo donahue]

I really don't want to take the performance hit of using SSL except on a couple of pages. The content
is just not that sensitive.

I thought you could specifiy which pages in your webapp need to use SSL using a security constraint and web resource collection with a url-pattern for the pages you want under SSL?

In this simplified example, every jsp page is under SSL.

    <!-- SECURITY CONSTRAINT -->
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>samplewebapp</web-resource-name>
            <url-pattern>*.jsp</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
	<role-name>some_role_name</role-name>
        </auth-constraint>
        <user-data-constraint>
	<transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

    <!-- LOGIN CONFIGURATION-->
    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>JNDIRealm</realm-name>
    </login-config>

    <!-- Security roles referenced by this web application -->
    <security-role>
        <role-name>some_role_name</role-name>
    </security-role>

I also agree with Tim in that if you use BASIC auth under SSL, your webserver or container will issue a challenge to the user in the form of a dialogue prompting for username/password. You don't "have" to write a login page, unless you don't like the aesthetics of the varying dialogue, it looks different in IE vs Firefox. If you decide to write your own form-based login page, even under SSL, you now have to deal with people that try to pass junk into your webapp via hacking the POST URL.

Tim, I'd love to see that list you're working on.

[Tim Holloway]

The key thing to keep in mind is that's what's being controlled is the protocol that's required when a user submits a URL request. On the outbound (response), you can send back URLs in any form you want. But, of course, if the URLs you send don't match what the server demands, at best, you be challenged to switch to the proper protocol and at worst, the request will be rejected outright.

Here's my link to Why Do-it-Yourself Java Security is a BAD THING.

[Richard Grin]

Tim Holloway wrote:

Brendan Healey wrote:You probably know the scenario by now - you're putting an application together (I'm using JSF 2.0
on a glassFish v3 stack) and the very first thing you've got to do is write some login code.

No it's not. In most cases, I don't write ANY login code, because J2EE comes with a perfectly good authentication and authorization system of its own, pre-debugged, vetted by security professionals, and ready to use. And, since it's an integral part of J2EE, it automatically handles switching to secure channels at need.

Extract from the Java EE 6 tutorial (http://docs.oracle.com/javaee/6/tutorial/doc/gkbaa.html#gkbsa): "HTTP basic authentication and form-based authentication are not very secure authentication mechanisms. Basic authentication sends user names and passwords over the Internet as Base64-encoded text. Form-based authentication sends this data as plain text. In both cases, the target server is not authenticated. Therefore, these forms of authentication leave user data exposed and vulnerable. If someone can intercept the transmission, the user name and password information can easily be decoded.

However, when a secure transport mechanism, such as SSL, or security at the network level, such as the Internet Protocol Security (IPsec) protocol or virtual private network (VPN) strategies, is used in conjunction with basic or form-based authentication, some of these concerns can be alleviated."

So how could you have SSL only for authentication and not for the rest of the application?

[Tim Holloway]

Richard Grin wrote:
So how could you have SSL only for authentication and not for the rest of the application?

Welcome to the JavaRanch, Richard! But we'd prefer that you just start a new thread rather than revive one that's this old. Keeps things tidier that way, since most of the original participants have probably moved on.

In J(2)EE, you choose what URLs are handled via TLS/SSL by specifying URL patterns in web.xml and mapping transport to them.

However, once you've logged in, it's really NOT a good idea to switch back to plaintext transport. Your session identifier is constantly being passed back and forth and any secure objects within the session are therefore potentially at risk. That's one of the reasons that the traditional logout method is session.invalidate(). It guarantees that any secure objects will have been discarded from the conversation.

[Richard Grin]

Tim Holloway wrote:
Welcome to the JavaRanch, Richard! But we'd prefer that you just start a new thread rather than revive one that's this old. Keeps things tidier that way, since most of the original participants have probably moved on.

OK. It's too late I think for this post, but I will follow your advice for the future.

Tim Holloway wrote:
In J(2)EE, you choose what URLs are handled via TLS/SSL by specifying URL patterns in web.xml and mapping transport to them.

However, once you've logged in, it's really NOT a good idea to switch back to plaintext transport. Your session identifier is constantly being passed back and forth and any secure objects within the session are therefore potentially at risk. That's one of the reasons that the traditional logout method is session.invalidate(). It guarantees that any secure objects will have been discarded from the conversation.

Thanks for your quick answer. So, there is no good solution, except perhaps to program one's own solution, to send the login/password encrypted, without using SSL for all the session?

[Tim Holloway]

Writing your own login only makes it worse. The technical term for user-designed security system is "pwned".

The problem isn't J2EE preventing you from using insecure transport after login - it will allow that. The problem is that you'd have to be crazy to want to do so.

[Richard Grin]

Tim Holloway wrote:Writing your own login only makes it worse. The technical term for user-designed security system is "pwned".

The problem isn't J2EE preventing you from using insecure transport after login - it will allow that. The problem is that you'd have to be crazy to want to do so.

Sorry I don't understand "pwned" (I am French). But I agree with you :-) and I would not want to program my own solution for the security of my applications.

However, I can imagine an application without any secret data (for example organizing meetings) but I don't want that someone can use the identity of one of the other users (just as a game, by stealing passwords). In this case, I don't need SSL for the whole application but I don't want to send the login/password in clear (I would like to use my own form to enter login and password). Is there a simple solution with Java EE?

[Tim Holloway]

"pwned" isn't really English, it's hacker-speak meaning that someone/something else "owns" your server. As to why it's spelled that way, I never really learned, but it does sort of suggest that your server has been made into someone else's pawn.

There's no point in expecting to retain your identity if you're not using secure transport. The user's identity is attached to their session object, and if the session ID is being transported in the clear, then any eavesdropper can steal and use it. If you don't care about identity hijacking, then there's no real reason to use TLS even for login.

[Brendan Healey]

Here you go Tim: http://www.urbandictionary.com/define.php?term=pwned