Re: Security flaw in how Outlook verifies digital signatures
From: Vanguard (use_ReplyTo_at_domain.invalid)
Date: 02/18/05
- Next message: neo [mvp outlook]: "Re: Any danger in single-clicking e-mail?"
- Previous message: Roberto Franceschetti: "Re: Security flaw in how Outlook verifies digital signatures"
- In reply to: Roberto Franceschetti: "Re: Security flaw in how Outlook verifies digital signatures"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 17 Feb 2005 23:09:32 -0600
If you don't protect your private key for your certificate and anyone
gets it then they can purport to be you. The e-mail address specified
within the certificate is part of the identification you wish to use to
identify yourself but it need NOT be the delivery agent's e-mail
address. The certificate and its use in signing the *content* of a
message does not extend to verifying or authenticating the delivery
agent. When you buy a book from Prentice Hall or McGraw, do you really
think they were the author of the content within the book?
Don't expect different MUAs to behave the same regarding them comparing
the e-mail defined with the certificate used for signing the *content*
within a message and the From, Reply-To, Sender, or Return-Path headers
used to encapsulate the message in delivering it. If an MUA alerts you
that the sender envelope is different than the e-mail address specified
within the certificate then that's a feature of that MUA but it is not a
requirement of using S/MIME itself. Don't expect different MUAs even
from the same developer to behave the same. Stop confusing Outlook and
Outlook Express as though they share code, one is a lite version of the
other, or that they are even related products.
The public key portion of the certificate is deployed within the MIME
data (which is WITHIN the body of the message). It doesn't incorporate
anything of the headers which aren't even used in the delivery of the
message. Tell me, just how would you fix the problem so users could
still utilize a forwarding service or remailer which is then the sender
(i.e., delivery agent) of the digitally signed message and is obviously
not the e-mail address of the account used by the author that used their
certificate to sign their content?
If you can decipher the RFCs regarding S/MIME version 3, like
ftp://ftp.rfc-editor.org/in-notes/rfc3851.txt, then be my guest. I get
lost real quick in that muck. Section 3.1, says:
"S/MIME is used to secure MIME entities. A MIME entity can be a
sub-part, sub-parts of a message, or the whole message with all its
sub-parts. A MIME entity that is the whole message includes only the
MIME headers and MIME body, and does not include the RFC-822 headers."
Well, that pretty much says what I've said all along, that the headers
are NOT included in the digital signature. So an MUA that alerts you
that the e-mail address in the certificate differs from the sender
envelope information is optional but a nice feature nonetheless. After
all, Outlook Express doesn't alert you that the FollowUp-To header has
been used in a newsgroup post to which you reply (so your reply might
not go where you think it will). Some NNTP clients do alert you or you
can configure them to show up in the headers portion of the preview pane
so you know the FollowUp-To header got used. However, such an alert is
a feature of the program and NOT a requirement. The same for alerting
for a mismatch between the delivery agent (and whatever is its sender
envelope) and the e-mail address in the certificate used to sign an
e-mail. Nice to have but not mandatory to support S/MIME.
However, section 3.1 also says:
"Note that S/MIME can also be used to secure MIME entities used in
applications other than Internet mail. If protection of the RFC-822
headers is required, the use of the message/rfc822 MIME type is
explained later in this section."
The later explanation says:
"In order to protect outer, non-content related message headers (for
instance, the "Subject", "To", "From" and "CC" fields), the sending
client MAY wrap a full MIME message in a message/rfc822 wrapper in order
to apply S/MIME security services to these headers. It is up to the
receiving client to decide how to present these "inner" headers along
with the unprotected "outer" headers."
So look at your digitally signed messages to see if there is an outer
MIME part of type message/rfc822 that envelopes your inner MIME part
that carries the digital signature. So it is possible to include the
sender info in the signature but it is not required by the sender nor is
it required the receiving client support it. Do you know if Outlook
envelopes the S/MIME part for the signed content with another MIME part
of type message/rfc822? When you compile the same test messages in
Outlook Express using the same certificates, does OE wrap the S/MIME
content with another MIME part of type "message/rfc822"? I downloaded
your example message at http://www.logsat.com/Signatures/Valid.msg and
http://www.logsat.com/Signatures/Hacked1.msg (although they are a .msg
file instead of a text file). I did NOT see a MIME part with
"Content-Type: message/rfc822: ...". So whichever MUA you used to
generate this .msg file doesn't not include the RFC822 headers in the
signature. Having the receiving client *guess* by trying to compare the
e-mail address in the signature with the sender envelope info in the
headers is guaranteed to fail often. Since you MUA (Outlook?) did not
protect the headers, don't expect the receiving agent to authenticate
the headers.
This RFC 3851 was released in July 2004 and it takes awhile before MUAs
implement the changes (although they may implement the RFC before it
actually gets ratified). I did not see the "message/rfc822" content
type described in RFC 2311 to 2315 for S/MIME version 2, it wasn't
mentioned in RFCs 2630 to 2634 for S/MIME version 3.0, so it looks to be
something new to S/MIME (not that "message/rfc822" is a new content type
but of using it with S/MIME but which is still optional). I've seen
some RFCs over 6 years old that are still not implemented in some
clients. And then there is always the difference between the RFCs,
which are often a jumbled mess, and how they get implemented. But, in
my experience, the sender envelope has not been a part of any digitally
signed message that I have received. Apparently message/rfc822 wasn't
included in the test e-mails that you used, too.
- Next message: neo [mvp outlook]: "Re: Any danger in single-clicking e-mail?"
- Previous message: Roberto Franceschetti: "Re: Security flaw in how Outlook verifies digital signatures"
- In reply to: Roberto Franceschetti: "Re: Security flaw in how Outlook verifies digital signatures"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
