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
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
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.
The text was updated successfully, but these errors were encountered:
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.
Section 3. The Specification:
Subsection 6.6. Protecting Data in Transit
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:
security.42.2.0.192.in-addr.arpa. TXT https://domain/.well-known/security.txt
ORsecurity.2.0.192.in-addr.arpa. TXT https://domain/.well-known/security.txt
ORsecurity.0.192.in-addr.arpa. TXT https://domain/.well-known/security.txt
ORsecurity.192.in-addr.arpa. TXT https://domain/.well-known/security.txt
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.
The text was updated successfully, but these errors were encountered: