It's amazing about how many people try to make SSL/TLS a silver bullet that
solves all security problems. Hate to bust your bubbles, but NOT!
A typical SSL/TLS session will ONLY encrypt the data between the client and
the server and authenticate the SERVER. Even the assurance that the server
is really the server can be deceived with the help of a loose Certificate
Authority or IE.
All you people think that authentication through a SSL session and a http
form (most application servers do it today) will save you? Think again.
The form is just another web page. That means that those pesky hackers
already have access to your web server without you knowing who they are.
Hopefully, you've locked down those IIS servers! However, you have
SUCCESSFULLY prevented your network intrusion detection system from spotting
the hacking and alerting you to the potential problems. Bravo!
So if you need SSL to protect the data in transit, then make sure that you
are using host based systems to detect intrusions. If you don't need SSL to
protect the data, then don't use it.
Moral is: understand the technologies by knowing what they can do and can't
do.
Ron Ogle
Rennes, France
> -----Original Message-----
> From: Frank Knobbe [mailto:fknobbe (at) knobbeits (dot) com [email concealed]]
> Sent: Sunday, December 08, 2002 04:33 AM
> To: sjr (at) hushmail (dot) com [email concealed]
> Cc: focus-ms (at) securityfocus (dot) com [email concealed]
> Subject: Re: /Rpc virtual directory in IIS - How did it get there?
>
>
> On Wed, 2002-12-04 at 21:08, sjr (at) hushmail (dot) com [email concealed] wrote:
> > [...] Plus, we only allow SSL/TCP 443 traffic to it from
> the Internet, which generally wards off the most common IIS attacks.
> > [...]
>
> meeep .... wrong.
>
> SSL doesn't ward off attacks. Some worms that don't use SSL may not be
> able to get you, but SSL does nothing for security
> vulnerabilities, i.e.
> it doesn't make you not vulnerable against Unicode et. al.
>
> You can still run exploits over SSL and hack a box. One just needs to
> rig the attack scripts to use SSL, that's all. Don't think
> that because
> you are using SSL, you are secure.
>
> Regards,
> Frank
>
>
solves all security problems. Hate to bust your bubbles, but NOT!
A typical SSL/TLS session will ONLY encrypt the data between the client and
the server and authenticate the SERVER. Even the assurance that the server
is really the server can be deceived with the help of a loose Certificate
Authority or IE.
All you people think that authentication through a SSL session and a http
form (most application servers do it today) will save you? Think again.
The form is just another web page. That means that those pesky hackers
already have access to your web server without you knowing who they are.
Hopefully, you've locked down those IIS servers! However, you have
SUCCESSFULLY prevented your network intrusion detection system from spotting
the hacking and alerting you to the potential problems. Bravo!
So if you need SSL to protect the data in transit, then make sure that you
are using host based systems to detect intrusions. If you don't need SSL to
protect the data, then don't use it.
Moral is: understand the technologies by knowing what they can do and can't
do.
Ron Ogle
Rennes, France
> -----Original Message-----
> From: Frank Knobbe [mailto:fknobbe (at) knobbeits (dot) com [email concealed]]
> Sent: Sunday, December 08, 2002 04:33 AM
> To: sjr (at) hushmail (dot) com [email concealed]
> Cc: focus-ms (at) securityfocus (dot) com [email concealed]
> Subject: Re: /Rpc virtual directory in IIS - How did it get there?
>
>
> On Wed, 2002-12-04 at 21:08, sjr (at) hushmail (dot) com [email concealed] wrote:
> > [...] Plus, we only allow SSL/TCP 443 traffic to it from
> the Internet, which generally wards off the most common IIS attacks.
> > [...]
>
> meeep .... wrong.
>
> SSL doesn't ward off attacks. Some worms that don't use SSL may not be
> able to get you, but SSL does nothing for security
> vulnerabilities, i.e.
> it doesn't make you not vulnerable against Unicode et. al.
>
> You can still run exploits over SSL and hack a box. One just needs to
> rig the attack scripts to use SSL, that's all. Don't think
> that because
> you are using SSL, you are secure.
>
> Regards,
> Frank
>
>
[ reply ]