|
Posted by Mark Gamache on June 17, 2005, 2:26 pm
Please log in for more thread options
There is no question, if SSL is used incorrectly or that the PC has been
compromised, then SSL has risks. SSL MITM attacks require a compromised
machine or a user who clicks OK without understanding the implications. I'm
a big fan of tokens and mutual auth for these reasons.
--
Mark Gamache
Certified Security Solutions
http://www.css-security.com
>
>> assuming that you only allow the SSL to the Exchange OMA front end and
>> you
>> follow best practices in locking down the server, its all acceptable.
>>
>> The weak point in the security model has nothing to do with your question
>> (SSL). The weak point is the IIS server that runs OMA. SSL is bullet
>> proof.
>
> I agree that SSL is more or less acceptable for most OWA implementations.
>
> However, SSL is definitely NOT bulletproof. There are known
> vulnerabilities, some of which are trivial to exploit, especially in the
> default browser configuration. Do a google search for
> ssl-man-in-the-middle
> or "dsniff ssl" for some vulnerabilities. There are free tools that can
> sniff SSL. You can mitigate man in the middle attacks somewhat by using
> client certificates for mutual authentication.
>
> SSL 2.0, which is enabled by default on many popular browsers, has some
> other significant vulnerabilities. [I understand SSL 3.0 has some as
> well.]
> If the browser allows SSL 2.0, an attacker in the middle can remotely
> force
> the browser to downshift the connection to SSL 2.0 and attack it via those
> vulnerabilities. The user gets no notification.
>
> To prevent hijacking, SSL, PGP and other server identity validation
> schemes
> generally depend on the user to notice when the server's identity has not
> been correctly validated, and to do the right thing in response. If a
> user
> clicks "OK," the session continues as if nothing happened.
>
> If FIPS-140 certification is important to you, for example because you are
> a
> US federal government, note that SSL 2.0 and 3.0 are not FIPS certified.
> TLS 1.0 is newer and more secure and FIPS certified and should be used in
> place of SSL where possible. The strength of the SSL server certificate
> you
> implement theoretically also makes a difference.
>
> One thing is that nowadays it seems less likely that an attacker would be
> in
> a position to be able to sniff traffic passing in between you and the
> server. The most likely place to do this sniffing would be if the
> attacker
> is physically near the client or is on the same wired network segment as
> the
> client [or server] [or has remote control of an infected computer on your
> wired network segment]. This somewhat reduces the risk of an outsider
> performing such an attack, though an insider, someone in your company,
> would
> have an easier time of it.
>
> Given all this, it's curious that users, banks, etc. continue to feel so
> secure with the use of SSL. There is some some debate as to whether these
> issues should or should not spell the end of SSL. Clearly SSL is still
> being happily used, generally without reported incidents, even though most
> people don't seem to notice or care or make recommendations whether SSL
> 2.0,
> 3.0 or TLS is used. Perhaps this is because there really aren't too many
> good alternatives to SSL/TLS, and also because on the Internet you often
> don't have the ability to control how the client browser is configured.
>
>
| 
XML Sitemap