Nic Ferrier wrote,
> Miles Sabin wrote,
> > For instance, how to you handle the initial
> > key exchange?
>
> By manual methods...
Pretty secure, but not all that practical ("Before
registering with this site please give us your snail
mail address so we can post you your key" ;-)
> You're right that it's not as good as HTTPS. But as
> far as I know there are no servlet engines that
> support HTTPS.
Not so. Most commercial servlet engines support https,
and all(?) servlet plugins for traditional https-
supporting servers will at least be able to piggy-back
on the servers https support.
> HTTPS also has the following problems:
>
> 1. use outside the US isn't exactly easy, though I
> appreciate Apache has https because of mod_ssl (but
> then that don't work inside US)
Strong encryption is pretty easily available outside
of the US, both commercial and free, java and otherwise.
The only thing that US export policy does is prevent
US crypto companies from selling into non-US markets,
which is great for the local vendors (it's also why the
US export policies are in the process of being relaxed).
If you want a non-US secure Apache distro, take a look
at StrongHold,
http://www.int.c2.net/products/sh2/
That costs tho'. If you want something 100% Java and
free, try IAIKs SSL enhanced Jigsaw distribution,
http://jcewww.iaik.tu-graz.ac.at/Applications/jigsaw.htm
> 2. it's quite compelx for users to setup (they have to
> go an get certificates and so on - people are just
> confused by all of this)
Only if you require client certificates. If you just
want to guard against eavesdropping that's not
necessary.
> 3. one can have trouble using ANY ports other than 80
> across ultra conservative firewalls.
Hmm ... true enough, but there aren't going to be many
sites that won't let clients out through port 443 or
provide a tunnellable proxy as an alternative. And if
you're on the server end, you get your sysadmin to
reconfigure your firewall ;-)
> The benefits of my system are that it's quick and
> achievable.
If you don't mind pretty minimal security.
> Drawbacks are:
>
> - you probably MUST have users you know about outside
> of the web (ie: sending them postal keys)
Not terribly practical in many cases.
> - the applet thing which you address thus:
>
> > If an eavesdropper had access to a malicious or
> > compromised intemediary proxy then it'd actually be
> > extremely easy for them to catch applets and tweak
> > them on the fly, and there are no java security
> > checks which would save you.
>
> I don't see this... There are all sorts of tricks you
> can use to see if someone alters the applet as it
> crosses the wire... remember that it is only the first
> instance that is important (because after that you're
> just using the same applet)
>
> So.. the first instance could be checksummed... check
> for proxies across it's route and ensure that JS knows
> etc...
How does a checksum help? If an eavesdropper has
access to a malicious proxy they can catch the applet,
*and* the page it's embedded in, which means they can
tweak the applet *and* any javascript in the page that
might (tho' I'm not quite sure how) try and verify the
checksum.
Signed jars might help a little, but you'd have to rely
on the end user being suspicous if the applet arrived
unsigned or signed by another principal. If you're
worried about users have problems with client certs,
then you ought to be worried about this too.
> I don't think it's as depressing as you say - BUT!
> that doesn't mean I'm saying this is as secure as SSL.
Good.
> What I meant by my "nearlly as good" statement was
> that, considering the problems with SSL (including no
> servlet engine) and considering that this method works
> then it's not a bad fit.
>
> You wouldn't want to send national secrets over it, or
> even credit card details (though there are plenty of
> people happy to send these in the clear) but it is
> something and something is better than nothing.
Hmm ... if you're happy with weak security because
you're not sending things which are security critical
(not credit card details, and not passwords into sites
containing resources which are security critical), then
this method is OK. I'll go for that ...
But if that's the case, then why bother with encryption
at all? Or why not something trivial like ROT13, if all
you want to do is keep things from casual prying eyes?
Cheers,
Miles
--
Miles Sabin Cromwell Media
Internet Systems Architect 5/6 Glenthorne Mews
+44 (0)181 410 2230 London, W6 0LJ
[EMAIL PROTECTED] England
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
