I was wondering whether we could generate a hostname on startup, like SSH. However, I dont think you want a certificate without a fully qualified hostname, and asking the operating systems is probably not accurate in most cases. So that leaves prompting the user during startup.
I'd also like to point out again that a lot of users will do the HTTPS part using an Apache proxy, or a dedicated daemon like Pound. Partially because you should trust as few programs as possible with the key. So it should be possible to force redirection to HTTPS even when the container does not support SSL. -Arne Andrea Aime wrote: > Hey all, > so I've been looking at how to have GeoServer automatically switch to > HTTPS when user credentials are on the fence and/or when we do have > possibly sensible information running over the wire. > The two use cases I have in mind are: > - admin console, whenever an administrator logs in and edits > store/layer information, that should happen over SSL > - any data transfer that requires the user to authenticate > (meaning that the user credentials are stored in http basic > authentication headers, and that the information being > transferred might be sensible as well). > > So basically what seems to be needed is: > - have the authentication form post to an HTTPS url > - have all secure pages force a redirect to HTTPS if they > are hit thru a non secure URL > - have all OGC service requests using http basic authentication > switch to HTTPS by default > - have the responses asking the user to authenticate using > HTTP basic include a redirect to HTTPS first (that is, first > redirect to HTTPS, then tell the client that the user does not > have enough credentials and ask for them using a HTTP 401 > response. At that point the browser will pop up a user > credential request, but the whole communication will be > switched to https already). > > Am I missing anything? > > There are two more things to discuss. The first is that the > container might not have SSL enabled. Acegi has a class > that performs redirection only if SSL is there, but it > requires one to configure the SSL ports in the application > context... bah! Not very useful as people can be using > custom ones... I'll have to find a way to make this runtime > configurable (maybe turn it into a GeoServerInfo parameter?). > > The second issue is, what do we do for development and > demo (release) purposes? Setting up a SSL layer requires > one to create a certificate, a keystore and whatnot. > This guide provides some hint: > http://docs.codehaus.org/display/JETTY/How+to+configure+SSL > > I would say that for development purposes we should setup > a keystore with a well known setup and give Start.java > an option to use it, so that we can do tests with both > SSL enabled or not. The certificate will be valid for localhost > only, maybe the browser will get grumpy the first time and > ask us if we want to really trust that self signed certificate, > but from there on it should be smooth ride. > > What about release? The Jetty configuration we ship with > actually has a keystore ready, one just has to include > the jetty-ssl.xml config file in the command line. Try > with: > java -DGEOSERVER_DATA_DIR=... -jar start.jar etc/jetty.xml etc/jetty-ssl.xml > > and then try to connect to http://localhost:8443/geoserver > and you'll see. > We could just enable this by default but... as Arne pointed > out, it would give people a false sense of security, > since everybody knows the private key of that certificate > so it's possible to hijack those ssl communications without > much effort. > The only way to get real security is to have people > buy/create and install their own certificates... > > Opinions? Help very much appreciated, I'm no security expert ;-) > Cheers > Andrea > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > -- Arne Kepp OpenGeo - http://opengeo.org Expert service straight from the developers ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
