-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No certificate verification #142
Comments
Imapfilter does check SSL certs. While setting a verify call back is one
way of validating certificates, imapfilter uses the simpler way of
calling SSL_get_verify_result(). You can see the logic in get_cert() in
cert.c.
Matthew
————————————————————————————————————————————————————
*Matthew Donald*
m: +61-(0)431 607 492
e: matthew@wsadmin.org
…On 26 November 2016 at 05:26, asentieri ***@***.***> wrote:
Apparently imapfilter is not checking the certificate after connecting to
the imap server, or I am missing something. If the DNS is compromised by
some hacker and imapfilter is directed to a fake IP address, the
certificate supplied by that IP address will be accepted as valid if it is
properly signed. What I mean is that if imapfilter is expecting to connect
to imap.xyz... and the server signed and valid certificate is from www.abc...,
the connection will go through even if that is not the expected server.
Apparently you have to use a SSL validate callback to solve that
(SSL_CTX_set_verify)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#142>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABjNiSO4S6O_EnzX1IIl5ou-FE3yX8Esks5rByhegaJpZM4K8ppf>
.
|
Matthew,
Thank you for your prompt answer. As I said I may be missing something,
but I did a test, which seems to point into a different direction.
On the IMAP account, in the config.lua file, I added something like:
account1 = IMAP {
server = 'www.google.com',
username = 'xxx',
password = 'xxx',
ssl = 'ssl23',
};
Then, on the /etc/hosts file I added a line like:
X.Y.W.Z www.google.com
So, when any program asks for the ip address of www.google.com, it will
receive X.Y.W.Z and not the Google real web site IP address. But X.Y.W.Z
is the IP address of my mail provider, which is Godaddy.
After the changes above, when I run imapfilter everything behaves as
normal, I mean, I get into my regular email account at Godaddy and
filter it. I checked the filtering results with my mail reader and the
filter is really working.
The strange part, however, is that the certificate I am getting from
Godaddy has a common name (CN) which is not www.google.com, but is the
name associated with the IP X.Y.W.Z (which, again, is not
www.google.com). I guess imapfilter program is checking if the
certificate supplied by the IP address is properly signed by a valid
certification authority and valid, but it is not checking the common
name. But one important SSL intent is to check if the connection is
going to a correct server and not to a fake one.
Now imagine this situation: someone supplies WI-FI for free and has a
poisoned DNS, which will always resolve to his own server. So, while I
am using this Wi-FI connection and trying to connect to Godaddy, the DNS
resolution supplied by the same Wi_FI connection points me to a fake
server, which has a valid certificate, properly signed, and which can be
gotten for free over the Internet, whose CN is www.xyz.com. Well, if
imapfilter is not comparing the server string (server =
'xyz.godaddy.com' in the table passed to the IMAP function) to the
common name in the certificate, it will accept the connection as valid,
and things like user/password may go over encrypted connection to a fake
server which could record and make bad use of it. Would you mind
checking on that? Or telling me what I am missing? My knowledge about
openssl is limited and I am using your program to have a better
understanding of this library.
Thanks,
Alberto
…On 11/25/2016 07:31 PM, Matthew Donald wrote:
Imapfilter does check SSL certs. While setting a verify call back is one
way of validating certificates, imapfilter uses the simpler way of
calling SSL_get_verify_result(). You can see the logic in get_cert() in
cert.c.
Matthew
————————————————————————————————————————————————————
*Matthew Donald*
m: +61-(0)431 607 492
e: ***@***.***
On 26 November 2016 at 05:26, asentieri ***@***.***> wrote:
> Apparently imapfilter is not checking the certificate after
connecting to
> the imap server, or I am missing something. If the DNS is compromised by
> some hacker and imapfilter is directed to a fake IP address, the
> certificate supplied by that IP address will be accepted as valid if
it is
> properly signed. What I mean is that if imapfilter is expecting to
connect
> to imap.xyz... and the server signed and valid certificate is from
www.abc...,
> the connection will go through even if that is not the expected server.
> Apparently you have to use a SSL validate callback to solve that
> (SSL_CTX_set_verify)
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#142>, or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/ABjNiSO4S6O_EnzX1IIl5ou-FE3yX8Esks5rByhegaJpZM4K8ppf>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#142 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AWpQqv_RYRTgc1X94XB9QSoNF9Y87cgsks5rB33igaJpZM4K8ppf>.
|
Ok, give me a week to look into this. I'm fully committed this week.
Matthew
————————————————————————————————————————————————————
*Matthew Donald*
m: +61-(0)431 607 492
e: matthew@wsadmin.org
…On 26 November 2016 at 17:08, asentieri ***@***.***> wrote:
Matthew,
Thank you for your prompt answer. As I said I may be missing something,
but I did a test, which seems to point into a different direction.
On the IMAP account, in the config.lua file, I added something like:
account1 = IMAP {
server = 'www.google.com',
username = 'xxx',
password = 'xxx',
ssl = 'ssl23',
};
Then, on the /etc/hosts file I added a line like:
X.Y.W.Z www.google.com
So, when any program asks for the ip address of www.google.com, it will
receive X.Y.W.Z and not the Google real web site IP address. But X.Y.W.Z
is the IP address of my mail provider, which is Godaddy.
After the changes above, when I run imapfilter everything behaves as
normal, I mean, I get into my regular email account at Godaddy and
filter it. I checked the filtering results with my mail reader and the
filter is really working.
The strange part, however, is that the certificate I am getting from
Godaddy has a common name (CN) which is not www.google.com, but is the
name associated with the IP X.Y.W.Z (which, again, is not
www.google.com). I guess imapfilter program is checking if the
certificate supplied by the IP address is properly signed by a valid
certification authority and valid, but it is not checking the common
name. But one important SSL intent is to check if the connection is
going to a correct server and not to a fake one.
Now imagine this situation: someone supplies WI-FI for free and has a
poisoned DNS, which will always resolve to his own server. So, while I
am using this Wi-FI connection and trying to connect to Godaddy, the DNS
resolution supplied by the same Wi_FI connection points me to a fake
server, which has a valid certificate, properly signed, and which can be
gotten for free over the Internet, whose CN is www.xyz.com. Well, if
imapfilter is not comparing the server string (server =
'xyz.godaddy.com' in the table passed to the IMAP function) to the
common name in the certificate, it will accept the connection as valid,
and things like user/password may go over encrypted connection to a fake
server which could record and make bad use of it. Would you mind
checking on that? Or telling me what I am missing? My knowledge about
openssl is limited and I am using your program to have a better
understanding of this library.
Thanks,
Alberto
On 11/25/2016 07:31 PM, Matthew Donald wrote:
> Imapfilter does check SSL certs. While setting a verify call back is one
> way of validating certificates, imapfilter uses the simpler way of
> calling SSL_get_verify_result(). You can see the logic in get_cert() in
> cert.c.
>
>
> Matthew
>
>
>
>
>
>
> ————————————————————————————————————————————————————
> *Matthew Donald*
> m: +61-(0)431 607 492
> e: ***@***.***
>
> On 26 November 2016 at 05:26, asentieri ***@***.***>
wrote:
>
> > Apparently imapfilter is not checking the certificate after
> connecting to
> > the imap server, or I am missing something. If the DNS is compromised
by
> > some hacker and imapfilter is directed to a fake IP address, the
> > certificate supplied by that IP address will be accepted as valid if
> it is
> > properly signed. What I mean is that if imapfilter is expecting to
> connect
> > to imap.xyz... and the server signed and valid certificate is from
> www.abc...,
> > the connection will go through even if that is not the expected server.
> > Apparently you have to use a SSL validate callback to solve that
> > (SSL_CTX_set_verify)
> >
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub
> > <#142>, or mute the thread
> >
> <https://github.com/notifications/unsubscribe-
auth/ABjNiSO4S6O_EnzX1IIl5ou-FE3yX8Esks5rByhegaJpZM4K8ppf>
> > .
> >
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#142 (comment)
>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AWpQqv_
RYRTgc1X94XB9QSoNF9Y87cgsks5rB33igaJpZM4K8ppf>.
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#142 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABjNiSCJFq6w6xDjyCRYs3oKV3lxoBhDks5rB8zEgaJpZM4K8ppf>
.
|
Friendly reminder that this is still an issue, and a pretty big one at that. All an intercepting attacker would need to do is to have a valid signed certificate for any domain, and imapfilter will happily accept it. Luckily, I think the fix is pretty simple. A few additional lines in cert.c ought to do it: https://wiki.openssl.org/index.php/Hostname_validation |
@lefcha any chance you could look at it? |
MITRE has assigned CVE-2016-10937 for this issue. |
Just pushed a commit that should add support for hostname validation: bf2515d It should work with OpenSSL 1.1.0 and later as described in the OpenSSL's Hostname validation page. From my simple tests it seems to work. Please give it a try and let me know how it works for you. Thanks! |
@lefcha this seems to work for me in the case mentioned earlier in this thread, thanks! |
Apparently imapfilter is not checking the certificate after connecting to the imap server, or I am missing something. If the DNS is compromised by some hacker and imapfilter is directed to a fake IP address, the certificate supplied by that IP address will be accepted as valid if it is properly signed. What I mean is that if imapfilter is expecting to connect to imap.xyz... and the server signed and valid certificate is from www.abc..., the connection will go through even if that is not the expected server. Apparently you have to use a SSL validate callback to solve that (SSL_CTX_set_verify)
The text was updated successfully, but these errors were encountered: