SSl, and encrypition in general, are only tools to help in providing
adequate security. In itself, encryption provides no security at all.
in the discussed example, the server is public and must thus be
accessible to anyone. This means that it should accept requests
from any client, with or without a "trusted" certificate. and anyway,
what is a trusted certificate? anyone can buy a cert from pki vendors,
and if you check their "license", you'll see that they take no responsibility
in certificate validity and the like. so you're on your own again:)
many times, many people think encryption is the solution. it's not.
it helps in building a secure environment, but it is not security in itself.
It'll gives you nothing to know that your site was broken using a 3DES
encrypted channel...
it takes longer with 3DES? No! it takes longer when it's less vulnerable.
One shouldn't forget that most attacks are based on weaknesses that
may theoritically be avoided. so don't use "theory" to derive security laws.
theory states that a well-coded, well-configured program is hard to attack.
practice showed that well-coded and well-configured programs/systems
are simply rare.
cheers,
mouss
At 15:42 02/02/01 -0600, [EMAIL PROTECTED] wrote:
>Being a little picky here - but SSL does not prevent sniffing. The
>encrypted data that can
>be sniffed has to be decrypted to be of any use. Provided you have a
>"strong" algorithm
>and a sufficient encryption level to make a brute-force attack futile (40
>or 56 bit would not
>be sufficient), the data should not be able to be decrypted. Just my two
>cents.
>
>Thanks!
>Chris
>
>
>Chris Hastings
>Manager, Network Security
>Network Computing Services
>Vanderbilt University Medical Center
>[EMAIL PROTECTED]
>
>
>
>
> "David
> Ishmael"
>
> <dishmael@windwardcg To: "'John Steniger'"
> <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
> .com>
> <[EMAIL PROTECTED]>
>
> Sent
> by: cc:
>
> firewalls-owner@List Subject: RE: Re[2]:
> Configuration Arguments... In House...
> s.GNAC.NET
>
>
>
>
>
> 02/02/2001 02:40
> PM
>
> Please respond
> to
>
> dishmael
>
>
>
>
>
>
>
>Although SSL is nice, I'd be more concerned with the actual storage of the
>credit card and personal information on the server. SSL prevents sniffing,
>but doesn't prevent a compromise on the server itself.
>
>David Ishmael, CCNA, IVCP
>Senior Network Management Engineer
>Windward Consulting Group, Inc.
>Phone: (703) 283-7564
>Pager: (888) 910-7094
>eFax: (425) 969-4707
>Fax: (703) 351-9428
>mailto:[EMAIL PROTECTED]
>mailto:[EMAIL PROTECTED]
>
>
>
>
>
>
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of John Steniger
>Sent: Friday, February 02, 2001 2:22 PM
>To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
>Subject: RE: Re[2]: Configuration Arguments... In House...
>
>
>SSL provides encryption of the data as it travels over the network. This
>way no one can sniff credit card #'s, ss#'s, etc.
>
>John J. Steniger
>Network and Security Specialist
>Familymeds, Inc.
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, February 02, 2001 12:29 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re[2]: Configuration Arguments... In House...
> >
> >
> > I want to make sure I understand one aspect of using an SSL
> > secured web server
> > on the internal network.
> >
> > SSL slows the attacker, forcing them through an
> > authentication challenge, and
> > gives you a layer of auditing. If the SSL authentication is
> > compromised, the
> > SSL server is just as vulnerable as a non-SSL server and
> > subject to the same
> > attacks. Is that right? Is there anything else that SSL
> > will do for you in
> > this circumstance?
> >
> > Thanks,
> >
> > Conrad Schellenberg
> >
> >
> > ____________________Reply Separator____________________
> > Subject: Re: Configuration Arguments... In House...
> > Author: "David Lang" <[EMAIL PROTECTED]>
> > Date: 2/2/2001 12:38 PM
> >
> > Brian, that depends on how your firewall passes 'only http traffic'
> >
> > for example Raptor checks the message from the client and
> > makes sure it is
> > a valid get/post/etc message, then it checks the response
> > from the server
> > and makes sure it's also valid. It does this for each request.
> >
> > firewall-1 on the other hand may check the inital connection
> > to the server
> > to see if it's a get/post/etc but after that allows that connection
> > without spending more time on it.
> >
> > this means that if your inital connection triggers a bug on the server
> > (IIS but, buffer overflow, etc) that ends up giving you a comand/shell
> > prompt on the webserver if you have firewall-1 the attacker
> > can then type
> > commands on your webserver to download additional tools and
> > attack your
> > internal network from the webserver. Raptor watches the
> > entire exchange
> > and would prevent this.
> >
> > now no firewall can watch SSL connections so I'm not sure exactly what
> > happens there. I don't know how many (if any) of the exploits
> > can be used
> > against SSL servers and continue to be exploited after the
> > webserver is
> > compramised.
> >
> > David Lang
> >
> >
> >
> > On Fri, 2 Feb 2001, Brian Steele wrote:
> >
> > > Date: Fri, 2 Feb 2001 12:20:10 -0400
> > > From: Brian Steele <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Configuration Arguments... In House...
> > >
> > > Hmm.. Can someone give an example of how a "compromise"
> > that opens the
> > > internal network to the attacker could work, if the proxy
> > server is passing
> > > only HTTP traffic on port 80 between the internal server
> > and the Internet
> > > client?
> > >
> > >
> > > Brian
> > >
> > >
> > > ----- Original Message -----
> > > From: "Paul Cardon" <[EMAIL PROTECTED]>
> > > To: "Kelly Slavens" <[EMAIL PROTECTED]>
> > > Cc: <[EMAIL PROTECTED]>
> > > Sent: Friday, February 02, 2001 11:55 AM
> > > Subject: Re: Configuration Arguments... In House...
> > >
> > >
> > > > Kelly Slavens wrote:
> > > > >
> > > > > I have a situation where I have a Server,
> > which will host web
> > > > > content from "Internal" Data to the external world.
> > This Server Needs
> > > only
> > > > > have web services accessible to the outside world
> > beyond our network.
> > > Our
> > > > > current configuration is a Cisco Hardware Nat/Router
> > Packet filter
> > > directly
> > > > > connected to the Internet connection. Connected to that
> > is our MSProx2.0
> > > > > (Being replaced with ISA Server soon)... One individual
> > wishes to place
> > > this
> > > > > new web server directly behind the NAT alongside the
> > Prox, With a so
> > > called
> > > > > "one way" push only network connection to the internal
> > network. This
> > > seems
> > > > > like a bad idea to me. My suggestion was Place the Web
> > server behind the
> > > > > prox and use Reverse prox to redirect all web traffic
> > to only this
> > > single
> > > > > internal Web server. This to me seems to be more secure
> > than a second
> > > > > machine sitting in the DMZ with a connection to the
> > internal network.
> > > >
> > > > With the web server behind the Proxy, if the web server
> > is compromised
> > > > (eg. IIS Unicode vulnerability) then the entire internal
> > network is open
> > > > to the attacker. The other configuration is better but
> > it isn't the
> > > > only solution.
> > > >
> > > > -paul
> > > > -
> > > > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > > > "unsubscribe firewalls" in the body of the message.]
> > >
> > > -
> > > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > > "unsubscribe firewalls" in the body of the message.]
> > >
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> >
> >
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> >
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
>
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
>
>
>
>
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
