Tomcat, garder la session lors du passage de HTTPS en HTTP

J'ai une application Java s'exécutant sur Tomcat 6.0.29, avec Apache 2.2.3 devant.
La page de connexion utilise le protocole HTTPS, alors que la plupart des pages utiliser HTTP.

Si un utilisateur tente d'accéder à une page (HTTP) qui est connexion protégée, il obtient redirigé vers la page de connexion (HTTPS), se connecte, puis obtient redirigé vers l'origine de la requête de la page.
Cela fonctionne très bien, comme le JSESSIONID cookie est défini comme non sécurisé, et utilisé pour HTTP et HTTPS.

Toutefois, si l'utilisateur commence à la page de connexion (HTTPS), le JSESSIONID cookie est défini comme Sécurisé, et donc la session n'est pas disponible après la connexion lors de la redirection vers des pages en HTTP, en imposant une nouvelle session et le rediriger vers la page de connexion à nouveau. Cette fois, il fonctionne bien, parce que cette fois le cookie JSESSIONID est défini comme non sécurisé.

Comment puis-je éviter que les utilisateurs de se connecter à deux fois quand ils ont frappé la page de connexion en premier?

double possible de HTTPS connexion n'enregistrant pas le JSESSIONID dans un cookie
Merci @leonbloy. Il est très lié oui (sauf que je suis dans le contrôle de la page de connexion de moi-même). La solution pour ajouter un non cookie de sécurité dans un filtre pourrait le faire. Mais il se sent comme un hack, il doit y avoir une meilleure façon..
La solution la plus simple serait probablement de faire comme 98% des sites y, laissez la page de connexion de l'insécurité, alors que l'affichage d'une URL sécurisée. Mais c'est un problème de sécurité, comme un homme dans le milieu pourrait changer l'URL de message et de recueillir des noms d'utilisateur/mots de passe
Vous pourriez faire la chose la plus sensée et d'avoir l'ensemble du site nécessitant une authentification derrière https. Si vous envoyez auth cookies et sans doute limité de données non garanti, alors il n'y a aucun point d'avoir protégé formulaire de connexion pour commencer.
Je sais, mais ce n'est pas une grande menace pour cette application particulière. Il y a quelques fils sur DONC sur les avantages et les inconvénients de l'exécution pure le protocole HTTPS. J'ai lu, et ma conclusion est que je ne veux pas. Comme la plupart des sites par exemple stackoverflow.com

OriginalL'auteur rlovtang | 2011-01-08

  1. 7

    (Mise à jour: pour plus de clarté) de Départ avec la connexion Http get/post l'utilisation de https et utiliser le protocole https par l'utilisateur est connecté en session.

    Utiliser Http uniquement lorsqu'il n'existe aucun utilisateur connecté.

    Il ya une raison que les cookies ne sont pas autoriser à traverser protocole limites - il est un vecteur d'attaque! (* voir la mise à jour ci-dessous)

    Comment ce faire de très mauvaise idée

    Si vraiment vous insistez, encoder le jsessionId dans le rediriger vers l'url http ( ou encode le jsession id dans l'url). Lorsque Tomcat obtient la redirection http, tomcat doit trouver de la session et de continuer.

    Pourquoi vous ne devriez pas faire ce

    Sérieusement, n'importe quel site qui mêle https et http du contenu sur la même page est seulement en s'ouvrant à toutes sortes de plaisir (et facile) d'attaques.

    Allant de https pour maintenir la connexion "sécurisée" est inutile si le reste de la session est en clair. Donc, ce que le nom d'utilisateur/mot de passe (probablement juste le mot de passe) est protégé?

    À l'aide de la toujours populaire " man-in-the-middle attaque, l'attaquant ne fait que copier l'id de session et l'utilise pour avoir du plaisir. Car la plupart des sites n'ont pas d'échéance sessions de rester actif, le MIM a effectivement accès complet comme s'ils avaient le mot de passe.

    Si vous pensez que le https est coûteux en termes de performances look ici, ou tout simplement la recherche. Façon la plus simple pour améliorer https performance acceptable est de s'assurer que le serveur est le réglage de keep-alive sur la connexion.

    Donc, ce que vous dites, c'est que chaque site a une certaine forme de connexion, doit utiliser le protocole HTTPS pour toutes les pages, et les sites qui utilisent le protocole HTTP ne devez jamais utiliser les sessions.
    Pas de. Ce que je veux dire, c'est qu'une fois qu'un utilisateur se connecte à un site, tous à propos du trafic de ce site devraient être via https jusqu'à ce que l'utilisateur se déconnecte. J'ai juste modifié l'original de la réplique.
    Twitter, facebook, stackoverflow etc semble en désaccord
    Google et les banques d'accord. Hey mais allez-y faire et encoder l'url avec l'id de session. Si votre service n'est pas actif lorsque le risque est "que" de grandes, peu importe. Viens de réaliser que le Détournement de Session est une certitude. C'est pourquoi le mur de moutons ( wallofsheep.com ) existe.
    Merci @Pat, je suis conscient du risque. Recherche Google utilise le protocole HTTP, même si vous êtes connecté btw. Mais je suppose que vous vous référez à des produits Google, tels que Gmail et google Agenda. Ils, ainsi que des banques, affiche des données très sensibles. Les banques à même de protéger la connexion avec un jeton fourni par une calculatrice ou un SMS. Chaque application doit choisir son niveau de sécurité. Ma demande est en lecture seule et affiche les données qui pourraient aussi bien être public, mais est limitée à un groupe de personnes pour l'instant. Si quelqu'un détourne de la session, ils seront en mesure de voir où les trains sont et comment retardée ils sont. Pas de mal.

    OriginalL'auteur Pat