[FEATURE] NAV Endpoint security

[andrew-azarov]

Az igény összefoglalása / Summary of the request There is no CAA record and no DNSSEC, no OCSP Stapling on NAV endpoint. At this point there is no way to verify whether NAV endpoint is compromised or not, as it can practically be MiTMd via DNS poisoning and/or other listed methods, It has no DNSSEC so even if you check for DNSSEC in your DNS resolvers it's not going to help. A BGP hijacking attack, or root SSL poisoning, or local cache / resolver / DNS server poisoning allows with high probability to pretend to be an actual NAV endpoint and read/send data and manipulate financial information of the attacked target with MiTM. This requires certain (in case of SSL root poisoning - government level) resources but definitely achievable.

# echo "" | openssl s_client -connect api.onlineszamla.nav.gov.hu:443 -tls1_2  -tlsextdebug  -status 2>&1 | grep OCSP
OCSP response: no response sent
# dig CAA api.onlineszamla.nav.gov.hu onlineszamla.nav.gov.hu nav.gov.hu gov.hu +short  | grep issue && echo secure || echo not secure
not secure

DNSSEC Check

Az általam javasolt megoldás / The solution I propose Setup DNSSEC to prevent DNS attacks for the nav.gov.hu domain name. OCSP stapling with CAA records in DNS to prevent SSL hijacking. To prevent possible hijackings inflight encryption should be implemented as well .hu zone supports DNSSEC, CAA records are easily added in the domain name servers. OCSP stapling is supported by virtually any modern HTTPs server With CAA record you will designate selected certificate authorities which can issue your certificates. With OCSP stapling you sign the certificate with timed certificate authority signature key proving SSL activity on every request and allowing easy revocation in case of issue. With DNSSEC you sign your DNS records so they cannot be tampered with or updated without someone possessing the key.

Elfogadható alternatívák / Acceptable alternatives Certificate authority with certificates for signing API messages and authorization would prevent most of the issues due to requiring private key of the authority to read the messages. In this scenario NAV issues certificates which are applied to API clients' SSL. On the NAV endpoint the SSLs are verified with local private key and decrypted at the same time - this provides both authorization and decryption. PKI could also resolve these issues but requires modifications to encryption while the previous works with curl and any other TLS client. Alternatively dedicated (providing keys over alternative medium, ie post) symmetric HMAC signing and AES encryption (home baked TLS :/) is also a possibility.

Egyéb tartalom / Additional content https://en.wikipedia.org/wiki/OCSP_stapling https://tools.ietf.org/html/rfc6066 https://tools.ietf.org/html/rfc6961 https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization https://tools.ietf.org/html/rfc8659

[renced42]

Dear @andrew-azarov Thanks for your comments. Altough these are not developer questions (DNSSEC,OCSP,CAA) so I have been forwarded to the appropriate group. Related to the PKI question: Currently we don't plan to move to PKI-based solution.

[andrew-azarov]

Thank you, PKI shouldn't be necessary. As I mentioned it is one of the possibilities. The easiest at the moment is to turn on check of certificate and turn on all of the missing protections and turn on OCSP in https functions on clients.