bsd5tu1 wrote:
>Considering how security is such a threat and concern, why bother using
>standard sockets as opposed to secure sockets as defined in JSSE? I know it
>looks like it's a little more work, but are there other concerns, like
>being noticably slower, not supported on all OSes ( I wouldn't think this
>would be an issue, but who knows) or some other concerns?
You should probably just write some test cases both ways and run
benchmarks. Be sure to measure latency as well as throughput. The old
engineering proverb is "Bandwidth can be bought, but latency is forever."
Setup latency, i.e. the time it takes to make a connection, is often
substantially longer with SSL. If your application is making lots of
connections frequently, that can really hurt. HTTP has Keep-Alive; other
protocols, maybe not so much. If you're not interoperating with other
protocols, you can make your protocol keep-alive to amortize the connection
setup costs.
The actual encryption overhead might or might not matter. It kinda depends
on line speed. Encryption affects bandwidth as well as latency, and
latency is something you have to live with even if encrypt/decrypt itself
is far faster than your network line speed.
Also, it's often useful to be able to observe the bytes on the wire, using
something like Interarchy's traffic-observation feature, or even tcpdump.
If you always encrypt, there's no chance you'll ever be able to do that,
and when you need it, you really NEED it. So if you have an option to set
it up as encrypted or non-encrypted, I recommend you design that in from
the start. Never underestimate the value of observability, especially
during development.
Finally, SSL won't solve every security problem. If you download a
Trojan'ed executable over a bidirectionally authenticated SSL connection,
with super-reliable root certificates, you've still downloaded a Trojan'ed
executable that will still compromise the machine it's run on. The only
thing SSL did is ensure integrity (you got the exact Trojan'ed executable
the provider sent), confidentiality (no one else could tell what Trojan'ed
executable you got), and direct authenticity (the provider you got the
Trojan from is certified by its CA).
SSL tells you nothing about the real origin of the executable, its
provenance (how it got to the immediate provider), whether the other host
has been compromised, or countless other things that can utterly destroy
your security. If you don't cover those bases, then at best, SSL gives you
some defense against random eavesdroppers. What you really need to ask
yourself is this:
What are you trying to defend against?
If you don't know exactly what you're defending against, or what you SHOULD
defend against, then deploying SSL is just security theater.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
