Check if email is digitally signed using VB.Net
up vote
1
down vote
favorite
I would like to know if it's possible, using VB.Net, to check if an e-mail is digitally signed and who is the issuer of the certificate.
Using Extended MAPI Wrapper and Cryptography I was able to get the smime.p7m attachment from an e-mail and get the certificate information out of it (including the issuer), so it seemed like everything was working. The issue is that if I send an unsigned e-mail and manually attach a smime.p7m file, it will trick the code into thinking that the e-mail is signed.
Does anyone have a solution for this? I can also use other methods like Outlook Interop.
vb.net outlook mapi smime
add a comment |
up vote
1
down vote
favorite
I would like to know if it's possible, using VB.Net, to check if an e-mail is digitally signed and who is the issuer of the certificate.
Using Extended MAPI Wrapper and Cryptography I was able to get the smime.p7m attachment from an e-mail and get the certificate information out of it (including the issuer), so it seemed like everything was working. The issue is that if I send an unsigned e-mail and manually attach a smime.p7m file, it will trick the code into thinking that the e-mail is signed.
Does anyone have a solution for this? I can also use other methods like Outlook Interop.
vb.net outlook mapi smime
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I would like to know if it's possible, using VB.Net, to check if an e-mail is digitally signed and who is the issuer of the certificate.
Using Extended MAPI Wrapper and Cryptography I was able to get the smime.p7m attachment from an e-mail and get the certificate information out of it (including the issuer), so it seemed like everything was working. The issue is that if I send an unsigned e-mail and manually attach a smime.p7m file, it will trick the code into thinking that the e-mail is signed.
Does anyone have a solution for this? I can also use other methods like Outlook Interop.
vb.net outlook mapi smime
I would like to know if it's possible, using VB.Net, to check if an e-mail is digitally signed and who is the issuer of the certificate.
Using Extended MAPI Wrapper and Cryptography I was able to get the smime.p7m attachment from an e-mail and get the certificate information out of it (including the issuer), so it seemed like everything was working. The issue is that if I send an unsigned e-mail and manually attach a smime.p7m file, it will trick the code into thinking that the e-mail is signed.
Does anyone have a solution for this? I can also use other methods like Outlook Interop.
vb.net outlook mapi smime
vb.net outlook mapi smime
edited Nov 1 at 0:02
Blackwood
4,044122238
4,044122238
asked Oct 31 at 22:07
Fabio Leonardo
414
414
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
Outlook Object Model always tries to represent signed and encrypted messages as regular MailItem objects. The MessageClass property will return "IPM.Note". It goes as far as returning a fake IMessage object from the MailItem.MAPIOBJECT property.
If you are using Extended MAPI, you can read the PR_MESSAGE_CLASS property and check if its value corresponds to one of the signed/encrypted message classes (e.g. "IPM.Note.SMIME.MultipartSigned"). Just make sure to unwrap the IMessage object if you are retrieving it from the MailItem.MAPIOBJECT property.
You can also use Redemption and and its RDOEncryptedMessage object - it allows to decrypt an encrypted message using RDOEncryptedMessage.GetDecryptedMessage message as well as access the certificate properties.
add a comment |
up vote
0
down vote
If you have a truly signed S/MIME message, then the "smime.p7m" attachment will either have a Content-Type value of application/pkcs7-mime; smime-type=signed-data -or- it will have a Content-Type value of application/pkcs7-signature and will be the 2nd child MIME part of a multipart/signed container.
To visualize:
Option 1:
Content-Type: application/pkcs7-mime; smime-type="signed-data"; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
Option 2:
Content-Type: multipart/signed; boundary="some-bounary-string"; protocol="application/pkcs7-signature"
--some-boundary-string
Content-Type: text/plain
This is the message content that was signed...
--some-boundary-string
Content-Type: application/pkcs7-signature; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
...
--some-boundary-string--
I'm not familiar with the Exchange MAPI wrapper API, but there should be a way to get the Content-Type value. Depending on what that is, you can check for the other attributes I mentioned above to verify if it is actually a signed message or just an attachment.
Note: They can also be application/x-pkcs7-mime and application/x-pkcs7-signature, but other than the leading x- of the MIME subtype, the logic is the same.
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 at 11:17
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 at 13:27
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 at 13:30
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
Outlook Object Model always tries to represent signed and encrypted messages as regular MailItem objects. The MessageClass property will return "IPM.Note". It goes as far as returning a fake IMessage object from the MailItem.MAPIOBJECT property.
If you are using Extended MAPI, you can read the PR_MESSAGE_CLASS property and check if its value corresponds to one of the signed/encrypted message classes (e.g. "IPM.Note.SMIME.MultipartSigned"). Just make sure to unwrap the IMessage object if you are retrieving it from the MailItem.MAPIOBJECT property.
You can also use Redemption and and its RDOEncryptedMessage object - it allows to decrypt an encrypted message using RDOEncryptedMessage.GetDecryptedMessage message as well as access the certificate properties.
add a comment |
up vote
1
down vote
Outlook Object Model always tries to represent signed and encrypted messages as regular MailItem objects. The MessageClass property will return "IPM.Note". It goes as far as returning a fake IMessage object from the MailItem.MAPIOBJECT property.
If you are using Extended MAPI, you can read the PR_MESSAGE_CLASS property and check if its value corresponds to one of the signed/encrypted message classes (e.g. "IPM.Note.SMIME.MultipartSigned"). Just make sure to unwrap the IMessage object if you are retrieving it from the MailItem.MAPIOBJECT property.
You can also use Redemption and and its RDOEncryptedMessage object - it allows to decrypt an encrypted message using RDOEncryptedMessage.GetDecryptedMessage message as well as access the certificate properties.
add a comment |
up vote
1
down vote
up vote
1
down vote
Outlook Object Model always tries to represent signed and encrypted messages as regular MailItem objects. The MessageClass property will return "IPM.Note". It goes as far as returning a fake IMessage object from the MailItem.MAPIOBJECT property.
If you are using Extended MAPI, you can read the PR_MESSAGE_CLASS property and check if its value corresponds to one of the signed/encrypted message classes (e.g. "IPM.Note.SMIME.MultipartSigned"). Just make sure to unwrap the IMessage object if you are retrieving it from the MailItem.MAPIOBJECT property.
You can also use Redemption and and its RDOEncryptedMessage object - it allows to decrypt an encrypted message using RDOEncryptedMessage.GetDecryptedMessage message as well as access the certificate properties.
Outlook Object Model always tries to represent signed and encrypted messages as regular MailItem objects. The MessageClass property will return "IPM.Note". It goes as far as returning a fake IMessage object from the MailItem.MAPIOBJECT property.
If you are using Extended MAPI, you can read the PR_MESSAGE_CLASS property and check if its value corresponds to one of the signed/encrypted message classes (e.g. "IPM.Note.SMIME.MultipartSigned"). Just make sure to unwrap the IMessage object if you are retrieving it from the MailItem.MAPIOBJECT property.
You can also use Redemption and and its RDOEncryptedMessage object - it allows to decrypt an encrypted message using RDOEncryptedMessage.GetDecryptedMessage message as well as access the certificate properties.
answered Oct 31 at 23:30
Dmitry Streblechenko
41.8k32760
41.8k32760
add a comment |
add a comment |
up vote
0
down vote
If you have a truly signed S/MIME message, then the "smime.p7m" attachment will either have a Content-Type value of application/pkcs7-mime; smime-type=signed-data -or- it will have a Content-Type value of application/pkcs7-signature and will be the 2nd child MIME part of a multipart/signed container.
To visualize:
Option 1:
Content-Type: application/pkcs7-mime; smime-type="signed-data"; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
Option 2:
Content-Type: multipart/signed; boundary="some-bounary-string"; protocol="application/pkcs7-signature"
--some-boundary-string
Content-Type: text/plain
This is the message content that was signed...
--some-boundary-string
Content-Type: application/pkcs7-signature; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
...
--some-boundary-string--
I'm not familiar with the Exchange MAPI wrapper API, but there should be a way to get the Content-Type value. Depending on what that is, you can check for the other attributes I mentioned above to verify if it is actually a signed message or just an attachment.
Note: They can also be application/x-pkcs7-mime and application/x-pkcs7-signature, but other than the leading x- of the MIME subtype, the logic is the same.
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 at 11:17
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 at 13:27
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 at 13:30
add a comment |
up vote
0
down vote
If you have a truly signed S/MIME message, then the "smime.p7m" attachment will either have a Content-Type value of application/pkcs7-mime; smime-type=signed-data -or- it will have a Content-Type value of application/pkcs7-signature and will be the 2nd child MIME part of a multipart/signed container.
To visualize:
Option 1:
Content-Type: application/pkcs7-mime; smime-type="signed-data"; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
Option 2:
Content-Type: multipart/signed; boundary="some-bounary-string"; protocol="application/pkcs7-signature"
--some-boundary-string
Content-Type: text/plain
This is the message content that was signed...
--some-boundary-string
Content-Type: application/pkcs7-signature; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
...
--some-boundary-string--
I'm not familiar with the Exchange MAPI wrapper API, but there should be a way to get the Content-Type value. Depending on what that is, you can check for the other attributes I mentioned above to verify if it is actually a signed message or just an attachment.
Note: They can also be application/x-pkcs7-mime and application/x-pkcs7-signature, but other than the leading x- of the MIME subtype, the logic is the same.
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 at 11:17
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 at 13:27
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 at 13:30
add a comment |
up vote
0
down vote
up vote
0
down vote
If you have a truly signed S/MIME message, then the "smime.p7m" attachment will either have a Content-Type value of application/pkcs7-mime; smime-type=signed-data -or- it will have a Content-Type value of application/pkcs7-signature and will be the 2nd child MIME part of a multipart/signed container.
To visualize:
Option 1:
Content-Type: application/pkcs7-mime; smime-type="signed-data"; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
Option 2:
Content-Type: multipart/signed; boundary="some-bounary-string"; protocol="application/pkcs7-signature"
--some-boundary-string
Content-Type: text/plain
This is the message content that was signed...
--some-boundary-string
Content-Type: application/pkcs7-signature; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
...
--some-boundary-string--
I'm not familiar with the Exchange MAPI wrapper API, but there should be a way to get the Content-Type value. Depending on what that is, you can check for the other attributes I mentioned above to verify if it is actually a signed message or just an attachment.
Note: They can also be application/x-pkcs7-mime and application/x-pkcs7-signature, but other than the leading x- of the MIME subtype, the logic is the same.
If you have a truly signed S/MIME message, then the "smime.p7m" attachment will either have a Content-Type value of application/pkcs7-mime; smime-type=signed-data -or- it will have a Content-Type value of application/pkcs7-signature and will be the 2nd child MIME part of a multipart/signed container.
To visualize:
Option 1:
Content-Type: application/pkcs7-mime; smime-type="signed-data"; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
Option 2:
Content-Type: multipart/signed; boundary="some-bounary-string"; protocol="application/pkcs7-signature"
--some-boundary-string
Content-Type: text/plain
This is the message content that was signed...
--some-boundary-string
Content-Type: application/pkcs7-signature; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
...
--some-boundary-string--
I'm not familiar with the Exchange MAPI wrapper API, but there should be a way to get the Content-Type value. Depending on what that is, you can check for the other attributes I mentioned above to verify if it is actually a signed message or just an attachment.
Note: They can also be application/x-pkcs7-mime and application/x-pkcs7-signature, but other than the leading x- of the MIME subtype, the logic is the same.
answered Nov 10 at 19:17
jstedfast
18k15177
18k15177
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 at 11:17
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 at 13:27
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 at 13:30
add a comment |
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 at 11:17
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 at 13:27
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 at 13:30
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 at 11:17
But if I send a signed email and download it's smime.p7m file, it will have all this information that you said, and I can re-attach it to some other e-mail to make the code think that it's signed, I would just have to identify/modify the body part of the smime file (Content-Type: text/html) and keep the same certificate data.
– Fabio Leonardo
Nov 12 at 11:17
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 at 13:27
You're not making any sense. If you take the smime.p7m signature data from 1 message and add it to another message with a different text/html content, then it won't magically become a signed message. It won't even look that way unless you create a multipart/signed container that contains the text/html and the smime.p7m data with the correct Content-Type (if you try to attach a smime.p7m file using a mail client, it'll have a Content-Type of application/octet-stream, not application/pkcs7-signature - the mail client also won't add it to a multipart/signed, it'll add it to a multipart/mixed)
– jstedfast
Nov 12 at 13:27
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 at 13:30
Is it possible for someone with my level of knowledge to construct a message that will fool a client or library into thinking that a message looks signed when it isn't? Sure, but that's why you implement logic to verify the digital signature.
– jstedfast
Nov 12 at 13:30
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53092614%2fcheck-if-email-is-digitally-signed-using-vb-net%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown