You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
List the CVE ID(s) associated with this vulnerability. GitHub will automatically link CVE IDs to the GitHub Advisory Database.
CVEs pending
Report
Hostname verification is an essential part of Transport Layer Security (TLS) and HTTPS.
When a TLS connection is established there are two important steps:
First, the chain of trust is verified that means it is checked whether the certificate has been issued by a trusted certificate authority.
Second, the hostname (that is being connected to) needs to be verified against the certificate.
That means it is checked whether the certificate is actually for the hostname.
If the hostname is not verified an attacker could present any certificate with a valid chain of trust, but that is not issued for the hostname at all. This allows a man-in-the-middle attack!
Many posts tell developers that have problems with hostname verification to accept any certificate as valid in the case of a mismatch.
These problems usually are configuration problems that should be fixed instead.
Java verifies HTTPS hostnames by default.
But when a protocol uses TLS (SSLEngine) the hostname is not verified by default.
That's where the second part of my query (IncorrectHostnameVerifier.ql) comes into play.
[This PR and PR description is WIP]
87 of 642 projects tested have overridden the Hostname.verify method.
Query: github/codeql#3581
27 of 642 projects are detected by my currently running query.
Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc). We would love to have you spread the word about the good work you are doing
The text was updated successfully, but these errors were encountered:
CVE ID(s)
List the CVE ID(s) associated with this vulnerability. GitHub will automatically link CVE IDs to the GitHub Advisory Database.
Report
Hostname verification is an essential part of Transport Layer Security (TLS) and HTTPS.
When a TLS connection is established there are two important steps:
First, the chain of trust is verified that means it is checked whether the certificate has been issued by a trusted certificate authority.
Second, the hostname (that is being connected to) needs to be verified against the certificate.
That means it is checked whether the certificate is actually for the hostname.
If the hostname is not verified an attacker could present any certificate with a valid chain of trust, but that is not issued for the hostname at all.
This allows a man-in-the-middle attack!
Many posts tell developers that have problems with hostname verification to accept any certificate as valid in the case of a mismatch.
These problems usually are configuration problems that should be fixed instead.
Java verifies HTTPS hostnames by default.
But when a protocol uses TLS (SSLEngine) the hostname is not verified by default.
That's where the second part of my query (IncorrectHostnameVerifier.ql) comes into play.
[This PR and PR description is WIP]
87 of 642 projects tested have overridden the
Hostname.verify
method.Query: github/codeql#3581
27 of 642 projects are detected by my currently running query.
The text was updated successfully, but these errors were encountered: