Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
RE: SSL Regulations and Laws
From: Michael Johnson (mjohnso6optonline.net)
Date: Mon Jul 21 2003 - 18:24:02 CDT
I concur with SpeedM.
SSL is NOT the be-all, end-all. I offer two points to ponder:
1) I am aware of a vulnerability assessment firm that was able to find the
SSL keys on a project we were both working on using their proprietary
external tools to test vulnerabilities. www.complyguardnetworks.com
They also highlighted spyware, cross scripting, and SQL Injection weaknesses
on what was presumed a "secure" site. The moral of their story: test often,
fix what you find, and test again.
2) The overall architecture must be considered. Is the concern to protect an
individual account, or for that matter many? What happens to the data inside
the firewall after the SSL session has ended is probably equally as
dangerous. We are all aware of at least one financial firm that after they
got hacked through password rip off, the hacker found plenty of critical
data on the other side NOT encrypted or protected in any way.
From: SpeedMnmbc.com [mailto:SpeedMnmbc.com]
Sent: Monday, July 21, 2003 4:48 PM
Cc: calaiusa.net; ingoingostruck.de
Subject: RE: SSL Regulations and Laws
SSL is regarded by the general public as the end-all-be-all of webapp
security and it is truly far from it. I am sure that we don't need a
breakdown of what SSL does and how it does it, but we all need to remind
ourselves that users see the little lock in the corner of their browser
window and assume that the webapp that they are using is secure. We know
that this is not right.
SSL will make it near impossible, or at least way to difficult and time
consuming to decrypt traffic sent between client and webserver. So if
someone is snooping my traffic as I am paying bills online at my banks
website then they won't get my password. Am I the only one that realizes
how trivial this threat is? It is far more reasonable to assume that the
client would get hacked by a spyware virus or remote access trojan which has
a much higher probable rate of finding a password and private info than
spending time decrypting a ton of SSL encrypted packets?
I totally agree with Ingo, the security of the webapp itself is much more of
a threat. Who cares what encryption I have between me and my bank if the
bank's webapp is susceptible to SQL injection, XSS, or implements a flawed
From: Ingo Struck [mailto:ingoingostruck.de]
Sent: Monday, July 21, 2003 12:52 PM
Cc: Chackan Lai
-----BEGIN PGP SIGNED MESSAGE-----
> Of course, the other option is to have a java applet downloaded onto
> the browser and connect back via a full strength conection. This would
> bypass the browser SSL implementation and ensure that the connection
> is secure from anywhere/everywhere as long as the browser supports
> java. A few years ago, prior to the opening of export regulations,
> this method was the most popular to get around the issue of IE vs
> Netscape and export browsers vs full-strength.
However, this method has got two main drawbacks:
- - virtually any "security-aware-user" will immediately disallow the
of any applet / script code et al.
- - the remainder of the few who trust the server all the same will most
be cut off due to the incompatibilities linked to java awt/swing applet
Beyond those issues the risk of using not-well-secured applets (it's not an
easy task to do that right - most of the tries I saw failed) heavily
outweighs the "security boost" you gain from a 40 bit to 128 bit upgrade.
- From my point of view using script or any other executable code for
web-based applications, especially for "security-aware" apps, is *NEVER* an
Use PGP: http://ingostruck.de/ingostruck.gpg with fingerprint C700 9951 E759
1594 0807 5BBF 8508 AF92 19AA 3D24 -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
-----END PGP SIGNATURE-----