Skip to content
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

HTTPS MUST on IP addresses with certificate validation? #177

Open
asbjornst opened this issue Dec 14, 2019 · 1 comment
Open

HTTPS MUST on IP addresses with certificate validation? #177

asbjornst opened this issue Dec 14, 2019 · 1 comment

Comments

@asbjornst
Copy link

Section 3. The Specification:

The file is named "security.txt", and this file SHOULD be placed
under the /.well-known/ path ("/.well-known/security.txt") [RFC8615]
of a domain name or IP address for web properties.
[...]
For web-based services, the file MUST be accessible via [...],
and it MUST be served with "https" (as per section 2.7.2 of [RFC7230]).

Subsection 6.6. Protecting Data in Transit

[...] As part of the TLS handshake, implementors MUST validate the provided X.509 certificate [...]

As Let's Encrypt does not issue certificates for IP addresses.
While it may be possible to obtain IP address certificates it generally requires Organization Validation (OV) and that the IP's is registered to the organization in WHOIS.
I doubt that anybody will pay for these certificates for this purpose.

I see few possible solutions to this:

  • Convince Let's Encrypt to issue IP certificates (good luck)
  • Skip domain name check for IP addresses (bad)
  • Resolve IP of CN (and maybe SAN) and check that against the IP (hard to implement)
  • Allow HTTP for IP addresses, but then security.txt MUST be PGP signed.
  • Allow HTTP for IP addresses, but it MUST redirect to HTTPS with a domain name that resolves to the same IP.
  • Use TXT records on subdomain under the appropriate reverse DNS zone w/ DNSSEC
    • security.42.2.0.192.in-addr.arpa. TXT https://domain/.well-known/security.txt OR
    • security.2.0.192.in-addr.arpa. TXT https://domain/.well-known/security.txt OR
    • security.0.192.in-addr.arpa. TXT https://domain/.well-known/security.txt OR
    • security.192.in-addr.arpa. TXT https://domain/.well-known/security.txt
    • Same goes for IPv6 just with potentially a lot more lookups

The advantage of using DNS, is that non-HTTP services doesn't have to expose a web server, just because of security.txt. Additionally it's possible to announce a security.txt for a whole network at once. The downside is that it requires reverse zone control, and not all DNS server software may support TXT subdomains in reverse zones.
For those that can't do it the DNS way, one of the HTTP solutions might work.

@nightwatchcyber
Copy link
Contributor

Since existing HTTPS standard allow issuance of SSL certificates to IP addresses, the concerns you described would be out of scope for this draft. For the DNS proposal - this has been recommended before and we made a decision to explore alternative ways to deploy the file once the current draft is approved. One of those is TXT and DNS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants