COMMAND

    IE

SYSTEMS AFFECTED

    IE 5.0, 5.1

PROBLEM

    Frank Knobbe  found following.   Remember the  discovery by  Mitja
    Kolsek regarding  bypassing the  security warnings  when you  view
    SSL protected sites with an invalid certificate?  Back then  Frank
    asked him what warnings he meant since he never seen one.

    Apparently the reason  he never seen  that warning was  because he
    had configured  my Internet  Explorer (5.1)  to 'Check  for Server
    Certificate  Revocation'  and  'Check  for  Publisher  Certificate
    Revocation' (under the Advanced Tab in the Internet Options).

    Testing has  shown that  with these  checkboxes de-selected,  I.E.
    will warn about sites where the domain name doesn't match the  one
    listed  in  the  certificate  (to  warn  you about site spoofing).
    However, with these checkboxes  selected, no warning is  presented
    at all.

    To verify select  above  mentioned  settings. Get the   IP address
    of your favorite SSL protected  site and enter it into  your local
    HOST file with  a mock domain  name (for example  test.com).  Then
    open  I.E.   and  go  to  https://test.com  and  the  page will be
    displayed  without  any  warning  notifications.   It displays the
    lock in the Status Bar as usual.

    When you do  a right click  on the page  and check the  status, it
    will list that it can not validate the certificate, as it  should.
    It's just  that no  warning will  be presented  to alert  the user
    that the site is not valid.

    It is unknown if this problem only occurs on SSL certificates that
    do not  list a  revocation URL,  or if  it applies  to all  certs.
    Frank tested it on patched and unpatched versions of I.E. 5.0  and
    5.1.

SOLUTION

    Well, obviously de-select the mentioned settings.

    For  web  site  operators:  Implement  anti-spoofing  redirections
    (which more and more  are using, that's good).   This is merely  a
    suggestions.  It  does not in  any way present  a solution to  the
    problem or even provide a workaround.  The only workaround so  far
    is to disable the Cert Revocation Check settings.

    For certificate issuer: Make  use of standards and  implement them
    fully.  List a revocation URL in the certificate if you have  one.
    The current state is that not every CA adheres to the practice  of
    including CRL (Certificate Revocation List) URL's in the SSL  cert
    issued to a website operator.  Hence there is no guarantee  to web
    browser/web surfers that the SSL  protected site is in fact  still
    valid.  Since certificates have an expiration date, an invalidated
    certificate would expire, but no immediate revocation check can be
    performed.  So  why do we  have these settings  in I.E. if  no one
    uses them?  Issuers should  include CRL URL's in the  certificates
    and browser should check them. Otherwise, how can we trust that  a
    certificate is  still valid?   Well, wouldn't  be so  bad if  I.E.
    would just ignore the fact that no CRL is present, but  apparently
    is ignores far more than that with these setting turned on...

    Anti-Spoofing Redirects: Well, you probably won't find that in any
    dictionary.  What writer meant by it is this.  Most web sites  can
    be addressed by their domain name or IP address in the URL.  If  a
    fake domain name is configured with the correct IP address, a  web
    browser will  connect to  fake.com (which  has the  IP address of,
    let's say, nbc.com) and display the content as usual (the  content
    of nbc.com).    The  URL still  says fake.com.   The Anti-Spoofing
    Redirection simply  checks the  URL and  if it  is not nbc.com (to
    stay with our example), it  will redirect the browser to  nbc.com.
    This is accomplished with a  few lines of server side  script code
    (i.e.   ASP).   The reason?  This will  guarantee that the browser
    displays the  correct URL.   A scenario,  where this  could be  of
    importance  might  be  a  fake  press announcement on the Internet
    claiming  that  ABC  bought  NBC.   At  the same time ABC's domain
    record is poisoned  or hijacked and  www.abc.com now actually  has
    the  IP  address  of  www.nbc.com.  A  browser  trying  to   reach
    www.abc.com will get the  pages from www.nbc.com although  the URL
    still  says  www.abc.com.  With  a  redirection  it  would display
    www.nbc.com.  Again,  this does nothing  to prevent the  hijacking
    of domains or copying  a web site to  be displayed on a  rogue web
    server.   NBC's web  site is  out of  the loop  so this suggestion
    does not stop or prevent this sort of thing.