It depends on the circumstances. I believe one widespread risk
among others might be the use of self-signed server certs
to establish a secure (ssl) communication.
If you use self-generated server certs,
someone could do a man-in-the-middle-attack,
making the client believe to communicate with the right server.
(I believe 'DNS spoofing' or manipulation of etc/hosts are ways
to place yourself betweena client and a server).
Since the client sends the symetric encryption key
to the wrong server (encrypted with the wrong public key),
it does not matter anymore whether the communication
were encrypted or not.
All data will be visible to the malicious server (not only
session ids).
The malicious server could additionally establish himself a
ssl connection to the originally intended server, using the
previously recorded login data for example.
>From now on, the man in the middle could forward client data
to the server and vice versa. This will all be done over ssl,
making the endpoints believe in a 'secure' connection.
One way to avoid trusting malicious servers is to use
certs issued be an 'official' certification agency (CA).
Another way might be to deliver selfsigned server certs to all
clients in a secure way (by messenger for example) and ask
the clients to import the server cert into their browser.
Too expensive ?! Thats why official CAs exist :-)
If you are concerned about someone stealing your information
(as your posting suggests) and just solved the problem of
trusting a malicious server, you might also wonder about
malicious clients ...
This will finally lead to client certs, smartcards etc.
But in the end even these security mechanisms have their weakness
(e.g. browser infection, social engineering).
I wouldn't even totally trust in biometric techniques like
fingerprints or retina analysis. Imagine a you were an
authorized client meeting a criminal surgeon :-)
> ........... I do not pass any confidential information
> as url parameters (ie. all forms are using post method).
Using the post or get method makes no difference
in man-in-the-middle attacks.
Gruss,
Wolfgang
___________________________________________
Even paranoids have enemies
-- Anonymous
___________________________________________
> -----Urspr�ngliche Nachricht-----
> Von: Taavi Tiirik [mailto:[EMAIL PROTECTED]]
> Gesendet: Freitag, 15. M�rz 2002 11:37
> An: Tomcat Users List
> Betreff: tomcat https security: is it possible to steal sessions?
>
>
> Hello,
>
> What kind of security risks are there if I use tomcat over https
> (http connector is disabled).
>
> Would it be ok to assume that nobody can listen traffic between
> tomcat and browser? I do not pass any confidential information
> as url parameters (ie. all forms are using post method).
>
> Is it still possible to (somehow) steal session info and act as
> somebody else?
>
> with best wishes,
> Taavi
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
