On 6 Jun 2001, at 20:41, Paul D. Robertson wrote:
On Thu, 7 Jun 2001, Ben Nagy wrote:
Nothing on the market currently prevents a malicious client
from being the
source of authentication, and that's the biggest tunnel issue
out there--
the Microsoft source code out the window
On 7 Jun 2001, at 18:11, Paul D. Robertson wrote:
On Thu, 7 Jun 2001 [EMAIL PROTECTED] wrote:
The problem is that everyone seems to _require_ HTTP/HTTPS access these
days, so there's your trojan's control vector happily provided either
directly, or via the corporate firewall.
On Thu, 7 Jun 2001 [EMAIL PROTECTED] wrote:
The problem is that everyone seems to _require_ HTTP/HTTPS access these
days, so there's your trojan's control vector happily provided either
directly, or via the corporate firewall.
And this is different from an on-site user, visiting the
On Thu, 7 Jun 2001 [EMAIL PROTECTED] wrote:
It's not, hence the words or via the corporate firewall.
If it's not, then the VPN is not a relevant part of the risk
scenario you're presenting. If the vulnerability is in allowing
machines on the trusted network to browse the web, then
Hi,
also does this. If you're doing user/password auth to actually bring up
the
VPN tunnel _as_well_as_ box auth (L2TP in IPSec does this, f'rinstance)
then
And - as L2TP is only kind of 'tunneled PPP' - you can then use any
authentication scheme that PPP supports (= as soon as there is wider
On 7 Jun 2001, at 19:23, Carl E. Mankinen wrote:
And this is different from an on-site user, visiting the web
through the corporate firewall, exactly HOW? i.e. I do not see how
this risk is exacerbated if the client connection comes across a VPN
tunnel rather than just a length
On Tue, 5 Jun 2001, Zachary Uram wrote:
Hi,
Is this article available online?
http://www.infosecuritymag.com/articles/may01/columns_tech_talk.shtml
[Disclaimer: My employer publishes the magazine]
I honestly think the magazine is well-worth subscribing to (despite my
contributions). In
On 5 Jun 2001, Abdulkareem Kusai wrote:
I share the same concern; can the inbound services we offer via the
internet using Sun iPlanet be penetrated without being detected since
the attack is transported within SSL? For example
IMAP/HTTP/SSL/TCP/IP. I would like for someone to convince me
I think this is why you want server-based IDS, as well as network-
based
(But this might also be a good reason to consider putting an SSL
accelerator box in front of your web server, so you can interpose a
network-based IDS between the two.)
David Gillett
On 5 Jun 2001, at 15:57,
A partial answer is to use host IDS on the destination machine. But this scenario is
flawed in my mind.
Lets ignore SSL for the moment. In your scenario you have an unpatched webserver that
is being exploited, yet you have an IDS system that knows about the exploit...
I guess you could
)
Subject Re: Encryption vs. inspection
, 2001 6:38 AM
Subject: Re: Encryption vs. inspection.
A partial answer is to use host IDS on the destination machine. But this
scenario is flawed in my mind.
Lets ignore SSL for the moment. In your scenario you have an unpatched
webserver that is being exploited, yet you have an IDS system
Thanks Paul!
Any other free security magazines I can get in USA?
Or any good non-free ones?
SDG,
Zach
On Wed, 6 Jun 2001, Paul D. Robertson wrote:
On Tue, 5 Jun 2001, Zachary Uram wrote:
Hi,
Is this article available online?
--- Steve Riley (MCS) [EMAIL PROTECTED]
wrote:
I think we all here agree that encryption is a good
thing. I won't
preach to the choir by enumerating the reasons. But
what about when
encryption prevents legitimate inspection?
If you are speaking of a VPN, encryption and
authentication
On Wed, 6 Jun 2001, Zachary Uram wrote:
Thanks Paul!
Any other free security magazines I can get in USA?
Or any good non-free ones?
The only other generic IT security magazine I've seen has been in Borders,
and I don't recall the name of it. I'm still compiling a list of
resources that
On Wed, 6 Jun 2001 [EMAIL PROTECTED] wrote:
An article by your TrueSecure CTO, Dr. Peter Tippet, in that issue is
also very illuminating on this. It explains that network sniffingis
much less of a problem than server security anyway. The risks that SSL
et al are aimed at are not the real
i think i'll wade into this flaming pit ...
i'm a big fan of strong crypto. anyone who knows me know that. i love
tunnels, i think they have a place. i think that paul's piece in
infosecmag is spot on in some places, and completely misses the boat in
others.
crypto, and tunnels, dont just
On Wed, 6 Jun 2001, Jose Nazario wrote:
i'm a big fan of strong crypto. anyone who knows me know that. i love
tunnels, i think they have a place. i think that paul's piece in
infosecmag is spot on in some places, and completely misses the boat in
others.
I'm interested in where you think I
i was digging around and came across a copy of these old
magazines i have:
#root, Sys Admin, Sun Expert
are these publications still around?
[EMAIL PROTECTED]
Blessed are those who have not seen and yet have faith. - John 20:29
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
:30 AM
To: [EMAIL PROTECTED]
Subject: Re: Encryption vs. inspection.
i think i'll wade into this flaming pit ...
i'm a big fan of strong crypto. anyone who knows me know that. i love
tunnels, i think they have a place. i think that paul's piece in
infosecmag is spot on in some places
On Wed, 6 Jun 2001, Paul D. Robertson wrote:
I'm interested in where you think I missed the boat- even after the
editor had at it, it still represents my position, though it's not a
complete representation due to space/audience limitations.
i think you forget about some things, like i noted
://www.theregister.co.uk/content/2/19442.html - Mankind's greatest
invention?
-Original Message-
From: Paul D. Robertson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 05, 2001 11:24 PM
To: Zachary Uram
Cc: Steve Riley (MCS); [EMAIL PROTECTED]
Subject: Re: Encryption vs. inspection.
On Tue, 5
i was digging around and came across a copy of these old
magazines i have:
#root, Sys Admin, Sun Expert
are these publications still around?
Sys Admin:
http://www.samag.com
Server/Workstation Expert:
http://swexpert.com/
#root:
http://www.nyhc.de/
Regards,
Dave
-
[To unsubscribe,
On Wed, 6 Jun 2001, Jose Nazario wrote:
sure they can. SSL, IPSec, etc .. all of those can force client side
authentication, not simply setup procedures.
That's a keying property though, not a tunnel property. IOW: there's
nothing in the tunnelness that mandates auth, and there's nothing
Jose Nazario wrote:
alternatively, and i haven't seen this done, include the NIDS in the
crypto negotiation via some secure key passing mechanism
might dsniff or one of its components fit well here?
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
unsubscribe firewalls in the body
yes, they are alive and kickin:
http://www.samag.com/
http://swexpert.com/
Thanks,
Ron DuFresne
On Wed, 6 Jun 2001, Zachary Uram wrote:
i was digging around and came across a copy of these old
magazines i have:
#root, Sys Admin, Sun Expert
are these publications still around?
-Original Message-
From: Steve Riley (MCS) [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 06, 2001 1:45 PM
To: [EMAIL PROTECTED]
Subject: RE: Encryption vs. inspection.
[SNIP]
The typical complaint against encrypted communications --
whether IPSec
transport mode
On Wed, 6 Jun 2001, Steve Riley (MCS) wrote:
The typical complaint against encrypted communications -- whether IPSec
transport mode or tunnels of various kinds -- is that once a machine is
compromised, then the attacker has a direct invisible route into other
machines. This seems a
Just some random comments...
-Original Message-
From: Paul D. Robertson [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 07, 2001 4:57 AM
To: Jose Nazario
Cc: [EMAIL PROTECTED]
Subject: Re: Encryption vs. inspection.
On Wed, 6 Jun 2001, Jose Nazario wrote:
[...]
i think
Services Australia Pty Ltd
Mb: +61 414 411 520 PGP Key ID: 0x1A86E304
-Original Message-
From: Michael Jinks [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 07, 2001 7:33 AM
To: Jose Nazario
Cc: [EMAIL PROTECTED]
Subject: Re: Encryption vs. inspection.
Jose Nazario wrote
On Thu, 7 Jun 2001, Ben Nagy wrote:
Nothing on the market currently prevents a malicious client
from being the
source of authentication, and that's the biggest tunnel issue
out there--
the Microsoft source code out the window stuff.
I take it you're talking about Joe Luser VPN'ing
On Wed, 6 Jun 2001, Michael Jinks wrote:
might dsniff or one of its components fit well here?
dsniff's crypto sniffing attacks work by fooling the user into accepting
the key proposed by the sniffer as the intended server's key. this can
occur when you have user intervention allowing those
On Wed, 6 Jun 2001, Steve Riley (MCS) wrote:
If (as Jose mentions) we force strong machine-to-machine
authentication, then the previous concern is moot: how can an attacker
compromise a machine at all? Am I missing something basic here, or is
it that simple? (No flames, please. :))
actually
On 06 Jun 2001 17:22:26 -0400, Paul D. Robertson wrote:
On Wed, 6 Jun 2001, Jose Nazario wrote:
That's a keying property though, not a tunnel property. IOW: there's
nothing in the tunnelness that mandates auth, and there's nothing about
the tunnel that makes a particular mechanism strong,
On Tue, 5 Jun 2001, Steve Riley (MCS) wrote:
I think we all here agree that encryption is a good thing. I won't
Not really, I think encryption can be a bad thing - as can tunneling in
general, hence my article in the last Information Security Magazine
issue...
preach to the choir by
I share the same concern; can the inbound services we offer via the internet using Sun
iPlanet be penetrated without being detected since the attack is transported within
SSL?
For example IMAP/HTTP/SSL/TCP/IP.
I would like for someone to convince me that my concern is unfounded. Any takers?
On Tue, 5 Jun 2001, Paul D. Robertson wrote:
Not really, I think encryption can be a bad thing - as can tunneling in
general, hence my article in the last Information Security Magazine
issue...
Hi,
Is this article available online?
[EMAIL PROTECTED]
Blessed are those who have not seen and
I share the same concern; can the inbound services we offer via the internet using Sun
iPlanet be penetrated without being detected since the attack is transported within
SSL?
For example IMAP/HTTP/SSL/TCP/IP.
I would like for someone to convince me that my concern is unfounded. Any takers?
[sorry, all, if this comes through twice - I've sent something since which
has arrived, but haven't seen this one come through]
-Original Message-
From: Steve Riley (MCS) [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 06, 2001 8:28 AM
To: [EMAIL PROTECTED]
Subject: Encryption vs
39 matches
Mail list logo
