Comments on: Day 7: ITSM Vulnerability Assessment techniques http://www.tssci-security.com/archives/2008/01/15/day-7-itsm-vulnerability-assessment-techniques/ top secret/secure computing information Fri, 21 Nov 2008 16:16:48 +0000 http://wordpress.org/?v=2.2.3 By: dre http://www.tssci-security.com/archives/2008/01/15/day-7-itsm-vulnerability-assessment-techniques/#comment-3906 dre Sat, 19 Jan 2008 23:42:59 +0000 http://www.tssci-security.com/archives/2008/01/15/day-7-itsm-vulnerability-assessment-techniques/#comment-3906 @ LonerVamp: I think everything before the SSL handshake will remain unencrypted. And DNS. And ICMP. It's not just about encryption, it's about authentication/authorization/auditing in web applications. If most web applications require user/password -- it would make sense that they also support real state/session management. Session management requires SSL and secure cookies along with HTTP. Until HTTP goes away, or changes, we're stuck with SSL. Although, there are possible alternatives such as Enigform, which was previously discussed on <a>Day 5 between myself and its author, Buanzo</a>. I really see these as three separate issues: 1) SSL as secure channel (to protect from MITM) 2) SSL as a part of session management (because HTTP doesn't have it) 3) SSL as a secure port listener wrapper, instead of parsing random protocols @ LonerVamp:

I think everything before the SSL handshake will remain unencrypted. And DNS. And ICMP.

It’s not just about encryption, it’s about authentication/authorization/auditing in web applications. If most web applications require user/password — it would make sense that they also support real state/session management. Session management requires SSL and secure cookies along with HTTP.

Until HTTP goes away, or changes, we’re stuck with SSL. Although, there are possible alternatives such as Enigform, which was previously discussed on Day 5 between myself and its author, Buanzo.

I really see these as three separate issues:
1) SSL as secure channel (to protect from MITM)
2) SSL as a part of session management (because HTTP doesn’t have it)
3) SSL as a secure port listener wrapper, instead of parsing random protocols

]]> By: LonerVamp http://www.tssci-security.com/archives/2008/01/15/day-7-itsm-vulnerability-assessment-techniques/#comment-3855 LonerVamp Fri, 18 Jan 2008 19:54:28 +0000 http://www.tssci-security.com/archives/2008/01/15/day-7-itsm-vulnerability-assessment-techniques/#comment-3855 It certainly is interesting trying to predict whether our network trafficks will tend towards encryption or tend towards being even more open....kinda like saying "information just wants to be free!" encryption going away could support that. Personally, someday we really do have to get around to having hardware outpace the software side, and provide more than plenty of head room to slap encryption on everything. I still think it is too economically difficult to encrypt *everything*, though I could be wrong and a bit behind the times already! :( Will we see everything encrypted someday? It certainly is a dream, but I'm not sure if we'll ever get there... Something to keep in mind as a mantra for many years to come! It certainly is interesting trying to predict whether our network trafficks will tend towards encryption or tend towards being even more open….kinda like saying “information just wants to be free!” encryption going away could support that.

Personally, someday we really do have to get around to having hardware outpace the software side, and provide more than plenty of head room to slap encryption on everything. I still think it is too economically difficult to encrypt *everything*, though I could be wrong and a bit behind the times already! :(

Will we see everything encrypted someday? It certainly is a dream, but I’m not sure if we’ll ever get there… Something to keep in mind as a mantra for many years to come!

]]>