search

internetstandards / Internet.nl

Internet standards compliance test suite
https://internet.nl
164 stars 36 forks source link

[Vraag] Mailserver Check DANE/STARTTLS & DNSSEC #1368

Closed websecnl closed 3 months ago

websecnl commented 3 months ago

Momenteel beoordelen jullie het niet hebben van een DANE/STARTTLS (TLSA) configuratie als een Medium Risk kwetsbaarheid. Maar dit is onredelijk gezien het niet hebben hiervan niet een direct security impact heeft, verder zijn er ook relatief veel mail providers die hier niet aan mee werken.. denk maar aan niet-nederlandse mail providers als hotmail, en GSuite Gmail.

Onze web applicaties krijgen dan een negatief score op internet.nl terwijl de score bij de mailserver hiervan onafhankelijk / apart beoordeeld zou moeten worden naar mijn mening.

Deze probleem speelt zich al best lang af, zie referentie: https://blog.rac.me.uk/2022/11/02/dnssec-signed-google-apps-g-suite-email/

Zelf loop ik nu tegen het zelfde probleem, ik gebruik de google mailservers welk wel DNSSEC heeft en STARTTLS ondersteund maar geen DANE configuratie heeft, dit is ook niet in te stellen in Gmail en het enige alternatief is om een aparte mailserver te configureren en dan deze weer in gmail in te stellen als een mail route (gok ik), of een abonnement te nemen bij een provider die wel DANE ondersteund en dit in gmail configueren bijv transip. maar dan moet ik dus geld betalen om en mijn hele mail configuratie overhoop gooien alleen om dit mogelijk te maken op een mail provider waar ik al voor geld betaal (Gmail), dat is een beetje absurd.

Mijn vraag is dan ook of jullie een score gescheiden kunnen houden voor de web applicatie en een score voor de mailserver, of in ieder geval voor de DANE checks geen medium risk hiervan maken maar op informationeel zoals het vroeger was. of als derde optie... Gmail en Hotmail kunnen whitelisten tijdelijk van DANE.

Alvast dank!

bwbroersma commented 3 months ago

@websecnl: I'm not aware of the terminology 'medium risk vulnerability' is being used. Could you point to this text on Internet.nl or the source code? Regarding the separation of the scores, these are already separated in a website and e-mail test, with a separate score.

websecnl commented 3 months ago

@websecnl: I'm not aware of the terminology 'medium risk vulnerability' is being used. Could you point to this text on Internet.nl or the source code? Regarding the separation of the scores, these are already separated in a website and e-mail test, with a separate score.

Apologies, I should have mentioned that this 'Medium Risk' term originates from https://basisbeveiliging.nl/report/NL/cyber/7226?tab=report_detail , but what I should have said 'red icon' which is more applicable to internet.nl's terms.

According to basisbeveiliging.nl the reason for them flagging this as a Medium Risk is because of internet.nl's decision to mark the missing DANE as a non-informational finding. (The blue icon with exclemation mark). In other words: Informational Mark did not affect the internet.nl score, however the red mark does. and this is why basisbeveiliging.nl will flag this as medium.

But aside from this, the point is that in some cases DANE can simply not be confiuged as its beyond the power of the domain admin, I do not have control over gmail's mailservers and cannot configure this because of this. so its strange to be taken into the metrics and affect the domain score, for this reason I believe that it should be changed back to informational.

bwbroersma commented 3 months ago

Internet.nl tests on the the requirements of the comply or explain list of The Netherlands Standardisation Forum, the TLS guidelines of the NCSC-NL, etc. The scoring is based on these requirements. Webserver or mailserver settings are not always in the boundary of the domain admin, the tests are not constrained to domain admin powers. Also see the explanation of test report.

DANE is for STARTTLS what HSTS is for HTTPS, without it a Man-in-the-Middle attack can be performed and the TLS can be stripped.

baknu commented 3 months ago

In addition to the above, we recommend you to request DANE support from your mail provider. Alternatively (but not necessarily recommended) you could run a DANE supporting mail relay.

DANE is supported by more and more mail providers, like Protonmail, Mailbox.org, Soverin and Startmail. Btw see also the Hall of Fame for Hosters. Futhermore, Cloudflare lately added (inbound) DANE to their mail platform. Microsoft already supports outbound DANE and plans to support inbound DANE mid 2024.

Below you will find some links to more background info. Hopefully these are useful to you.

MS already supports outbound DANE on Exchange Online and plans to support inbound DANE mid 2024:

websecnl commented 3 months ago

I understand, I agree with every word of the NCSC-NL guidlines. However making this a non-information finding is just unreasonable. Lets say I wish to get a 100% score, I will never be able to do so with this finding as long as I am using Gmail GSuite or Hotmail, which have a giant marketshare in the mail industry, obviously the fact that they (Google and Microsoft) dont have DANE won't result in any security impact any time soon so why should this still impact the score metrics of companies who are doing their best to get the best possible score. when you start scoring websites for things that are no longer within the scope of control the whole sense of the scoring system starts fading away.

That's why my suggestion is to make this DANE Check result status for specific trusted vendors informational, there is just nothing I can do about this right now unless I will reconfigure GMAIL over a custom SMTP (Which does have DANE supported, like the one from transip) which will further increase my monthly costs in addition to my Gmail GSuite costs.... only for the purpose of getting a better score on internet.nl , I am of the opinon that this is unreasonable.

websecnl commented 3 months ago

In addition to the above, we recommend you to request DANE support from your mail provider. Alternatively (but not necessarily recommended) you could run a DANE supporting mail relay.

DANE is supported by more and more mail providers, like Protonmail, Mailbox.org, Soverin and Startmail. Cloudflare lately added (inbound) DANE to their mail platform. Microsoft already supports outbound DANE and plans to support inbound DANE mid 2024.

Below you will find some links to more background info. Hopefully these are useful to you.

MS already supports outbound DANE on Exchange Online and plans to support inbound DANE mid 2024:

Exactly, and I do not want to have to order a new mailserver and go through all that fuss again, potentially even take a new subscription with some other vendor. I just want to stick to my trusted vendor GMail, I have a company to run and to just migrate everything over a single check 'DANE' is just not worth the expense. I will defiantly contact GMail about this but I am sure this does not affect only me but pretty much everyone who uses GMail without a custom SMTP Route to a DANE supported mailserver.

baknu commented 3 months ago

We believe DANE is a crucial standard to better secure mail server connections (which often transport even more sensitive data than website connections). Good thing that you are going to approach Google about this. Customer demand is often important to get vendors/providers moving. Anyway, I see no reason to change Internet.nl's assessment. This is about change and you don't achieve that by lowering the norm.

apio-sys commented 3 months ago

@websecnl (...)DANE Check result status for specific trusted vendors informational(...) I strongly disagree to this. What makes them trusted? The number of customers they have? Write yourself a waiver for not getting DANE in your IT Audit or use one of the other suggestions and/or put pressure on your current provider to adhere to common and modern Internet standards.

websecnl commented 3 months ago

@websecnl (...)DANE Check result status for specific trusted vendors informational(...) I strongly disagree to this. What makes them trusted? The number of customers they have? Write yourself a waiver for not getting DANE in your IT Audit or use one of the other suggestions and/or put pressure on your current provider to adhere to common and modern Internet standards.

I agree with all you guys statements here, I also have no clue why GMail is not just implementing this and this frustrates me. I'll make sure to inform them about this.

Internet.nl tests on the the requirements of the comply or explain list of The Netherlands Standardisation Forum, the TLS guidelines of the NCSC-NL, etc. The scoring is based on these requirements. Webserver or mailserver settings are not always in the boundary of the domain admin, the tests are not constrained to domain admin powers. Also see the explanation of test report.

DANE is for STARTTLS what HSTS is for HTTPS, without it a Man-in-the-Middle attack can be performed and the TLS can be stripped.

Yes I know, its like PKP but on a DNS level using DNSSEC. I like the whole Idea and I think its all for the better I agree with you on that. but comon, give me one example of where this has ever happened on Google or Microsoft Hotmail/O365. The only time I see this can happen is whenever the CA itself gets compromised, not having DANE does not mean that you are imidiatley at risk of downgrade attacks or MITM attacks, there are allot of other security measures which minimize this such as the CAA record.

But again, your points are valid. aside from the 'chances' pinning a trusted cert on DNS level would be much more secure than CAA or anything else for that matter. Only thing I'm saying is that it seems like i'm the only one here who sees that this is really Information or low risk at best.

websecnl commented 3 months ago

But anyways, i suppose the answer to the question is "Route GMail through a DANE Supported Provider" or "Get rid of Gmail", I'll close the thread. Thank you all for the replies 👍

baknu commented 3 months ago

Note that without DNSSEC/DANE there is no automatic way to authenticate the receiving mailserver and transport encryption is usually at best opportunistic (STARTTLS which is vulnerable to downgrades). Things like CAA do no change this. See:

We do not know how often these kind of attacks happen in practice, but they do happen:

bwbroersma commented 3 months ago

Microsoft nor Google cannot secure the the complete network path between every MTA out there and their MX against MitM. It's about stripping STARTTLS based on a network MitM, CAA cannot prevent this, since there is not TLS anymore.

websecnl commented 3 months ago

Note that without DNSSEC/DANE there is no automatic way to authenticate the receiving mailserver and transport encryption is usually at best opportunistic (STARTTLS which is vulnerable to downgrades). Things like CAA do no change this. See:

We do not know how often these kind of attacks happen in practice, but they do happen:

The examples provided should be resolved with DNSSEC alone, I do have DNSSEC. Infact.. I have pretty much everything except DANE and BIMI (Working on it).

websecnl commented 3 months ago

Microsoft nor Google cannot secure the the complete network path between every MTA out there and their MX against MitM. It's about stripping STARTTLS based on a network MitM, CAA cannot prevent this, since there is not TLS anymore.

I am using the DNSSEC + STARTTLS supported mailserver from google. they just dont have a TLSA setting for DANE. Attacks such as Cache Poisoning should not be possible with the current settings, only if a CA gets compromised and malicious certificates will get issued on my domain (Assuming that the compromised CA is the CA within my trusted CA's in the CAA record) in this extremley unlikely case it will be possible to perform MITM attacks. Please correct me if I am wrong.

bwbroersma commented 3 months ago

DANE is for STARTTLS what HSTS is for HTTPS, without it a Man-in-the-Middle attack can be performed and the TLS can be stripped.

DNSSEC (if done all the way) will result in a correct IP of the mail exchange (MX) server, however STARTTLS is not enforced by default, DANE will enforce it. If DANE is not present, the STARTTLS can be stripped from the SMTP EHLO server response (by a Man-in-the-Middle). This can be done by e.g. a network operator that is in the path. Also note that RPKI cannot protect against all BGP hijacks, a valid route can be prepended by an attacker (would be needed to be better peered).

Note that if the IP layer would be 'secure', TLS would not be needed.

websecnl commented 3 months ago

DANE is for STARTTLS what HSTS is for HTTPS, without it a Man-in-the-Middle attack can be performed and the TLS can be stripped.

DNSSEC (if done all the way) will result in a correct IP of the mail exchange (MX) server, however STARTTLS is not enforced by default, DANE will enforce it. If DANE is not present, the STARTTLS can be stripped from the SMTP EHLO server response (by a Man-in-the-Middle). This can be done by e.g. a network operator that is in the path. Also note that RPKI cannot protect against all BGP hijacks, a valid route can be prepended by an attacker (would be needed to be better peered).

Note that if the IP layer would be 'secure', TLS would not be needed.

Yea no need to explain that I am with you on this one, this is my understanding (I think it aligns with your statement); In a MITM Scenario that targets the SMTP the STARTTLS commands gets stripped from the EHLO response and then TLS cannot be initiated, resulting in a downgrade attack. (No need to compromise CA in this scenario) and since its not enforced by default (even if configured) pretty much the only option is to enable DANE.

But then again we come back to my point... that this is low risk at best, since this requires an attacker to have compromised the network. (Like a network operator in your example).

I'm not trying to be stubborn, I am writing here also just because of the best interest in my digital assets. I am working on DANE implementation as we speak, I dont intend on disregarding it. (I will implement DANE even if it means I have to move from Gmail) but lets be realistic here and @bwbroersma @baknu I hope you can at least agree with me on this; successfully exploiting a STARTTLS downgrade on Google Infrastructure (Gmail) is very very very unlikely... almost negligible. (Aside from whether internet.nl should remove the red icon to blue exclemation or not)

Personally I think the chance of google exidently exposing any of their private keys are higher then a downgrade attack happening successfully on their network layer within Google's Infrastructure.

So yeah, while I agree that DANE is important and while I will implement it. I do dispute / disagree with internet.nl's current risk score regarding this check.

bwbroersma commented 3 months ago

It's indeed easier to setup a fake Wifi hotspot and MitM traffic and StripTLS, than it is to MitM a SMTP server connection. From an BGP point of view the Google announcements are probably well monitored, but specific traffic, e.g. near the sending MTA might be easier. At least between 23-27 February this year there was an IPv6 incident with Google SMTP traffic that went unnoticed, so not everything is monitored for 0 routing/connection issues.

successfully exploiting a STARTTLS downgrade on Google Infrastructure (Gmail) is very very very unlikely... almost negligible

This is just an assumption. I don't like assumptions, most of the times they are your biggest mistakes. I assumed Google would monitor their incoming IPv6 traffic (see above). I would assume Google would run DNSSEC. I would assume the Google DMARC parser would be right. I would assume Google would not have XSS in Google Scholar which would successfully be used to have XSS in gmail (because there was a time you could also mix domains and products, found out his XSS while I was at university). And well, recently I thought KLM short codes cannot be scraped, see the talk. I had some same assumptions about banks, well I can go on and on.

Let me put it this way, stripping STARTTLS is very feasible if you know what your doing and are into networks. Did you read the jabber/xmpp.ru MitM and Mitigating the Hetzner/Linode XMPP.ru MitM interception incident? This incident went unnoticed for months, and only was discovered because of an expired certificate (BTW regarding your earlier CAA mention: in this incident an CAA letsencrypt.org without Account URI would not have helped). Please note not all strip-STARTTLS security failures are public, it's also not in the attackers interest to notify the users the communication is wire-tapped.

But I would say it's way harder to crack a RSA 1024 certificate (which is :x: failing the NCSC-NL guidelines and the HTTPS/STARTTLS test), than it is to MitM some third party MTA traffic to a Google SMTP server.