Security Professionals
- ipfw add deny all from eindgebruikers to any
Status SMTPS? (of hoe maken we e-mail nog veiliger)
29-09-2019, 20:13 door Anoniem, 10 reacties
(Maken we e-mail eigenlijk nog wel veiliger, of..... ?)
RFC 8314 is nog niet zo heel oud (Jan 2018) en gaat over TLS (beveiligde verbinding) van email.
https://tools.ietf.org/html/rfc8314
Ik denk dat nogal wat mensen hier m.b.v. STARTTLS een beveiligde verbinding denkt te krijgen voor e-mail.
Het is al vaker gezegd: dit is niet vanzelfsprekend. Want STARTTLS geeft je alleen een beveiligde verbinding in geval:
- de server waarmee je verbinding maakt dit ondersteunt.
- het STARTTLS-commando niet door een man-in-the-middle van de lijn wordt "weggestript"
(zodat het nooit aankomt bij de emailserver, en deze er dus ook niet adequaat op kan reageren)
Het is daarom veel beter dat er een beveiligde verbinding wordt gemaakt zónder dit "STARTTLS- houtje-touwtje-gedoe".
De Internet Engineering Task Force (IETF) heeft dit blijkbaar onlangs ook gemeen met RFC 8314.
Want wie wil er nu geen beveiligde verbinding als het over je emails gaat?
Dit zou tegenwoordig toch standaard en robuust moeten zijn?!
En daar gaat RFC8314 dus over: over het zo geheten "impliciete TLS".
moeten kunnen opzetten, zonder het brakke STARTTLS met zijn bijbehorende risico's hierbij nodig te hebben.
Meestal is bij e-mailproviders al impliciete TLS aanwezig voor IMAP en POP-servers.
Maar helaas niet bij SMTP, een server die wordt gebruikt bij het verzenden van mail.
Poort 587 wordt hier meestal voor gebruikt in combinatie met STARTTLS.
Maar poort 465 moet dus binnenkort impliciete TLS (SMTPS) gaan ondersteunen.
RFC8314 dringt er overigens op aan dat beide methoden nog enkele jaren naast elkaar moeten blijven bestaan. (overgangsfase)
IANA heeft poort 465 (TCP) hiervoor ook geregistreerd.
Volgens https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
Mijn eerste indruk is bijv. dat Ziggo na ca. 1 3/4 jaar nog steeds geen SMTPS over port 465 voor mekaar heeft,
gelet op hun instructies op het web. Google mail schijnt bijv. wel SMTPS aan te kunnen, ja zelfs ook MTA-STS:
https://www.security.nl/posting/604969/Gmail+eerste+grote+provider+die+MTA-STS-standaard+ondersteunt
Mijn vragen zijn:
1. Ken je NL-emailproviders die SMTPS (ca. 1 3/4 jaar na dato ...) wél hebben geïmplementeerd of er serieus mee bezig zijn, of loopt Nederland weer achter de feiten aan?
2. Nog nuttige op- of aanmerkingen over dit onderwerp?
mvg, Anno.
RFC 8314 is nog niet zo heel oud (Jan 2018) en gaat over TLS (beveiligde verbinding) van email.
https://tools.ietf.org/html/rfc8314
Ik denk dat nogal wat mensen hier m.b.v. STARTTLS een beveiligde verbinding denkt te krijgen voor e-mail.
Het is al vaker gezegd: dit is niet vanzelfsprekend. Want STARTTLS geeft je alleen een beveiligde verbinding in geval:
- de server waarmee je verbinding maakt dit ondersteunt.
- het STARTTLS-commando niet door een man-in-the-middle van de lijn wordt "weggestript"
(zodat het nooit aankomt bij de emailserver, en deze er dus ook niet adequaat op kan reageren)
Het is daarom veel beter dat er een beveiligde verbinding wordt gemaakt zónder dit "STARTTLS- houtje-touwtje-gedoe".
De Internet Engineering Task Force (IETF) heeft dit blijkbaar onlangs ook gemeen met RFC 8314.
Want wie wil er nu geen beveiligde verbinding als het over je emails gaat?
Dit zou tegenwoordig toch standaard en robuust moeten zijn?!
En daar gaat RFC8314 dus over: over het zo geheten "impliciete TLS".
Platte tekst wordt gezien als verouderd:
Dus gebruik transportlaagbeveiliging (TLS) voor e-mailindiening en -toegang
Dit houdt in dat mailservers (POP, IMAP of SMTP-server) voortaan standaard een impliciete beveiligde verbinding Dus gebruik transportlaagbeveiliging (TLS) voor e-mailindiening en -toegang
moeten kunnen opzetten, zonder het brakke STARTTLS met zijn bijbehorende risico's hierbij nodig te hebben.
Meestal is bij e-mailproviders al impliciete TLS aanwezig voor IMAP en POP-servers.
Maar helaas niet bij SMTP, een server die wordt gebruikt bij het verzenden van mail.
Poort 587 wordt hier meestal voor gebruikt in combinatie met STARTTLS.
Maar poort 465 moet dus binnenkort impliciete TLS (SMTPS) gaan ondersteunen.
RFC8314 dringt er overigens op aan dat beide methoden nog enkele jaren naast elkaar moeten blijven bestaan. (overgangsfase)
IANA heeft poort 465 (TCP) hiervoor ook geregistreerd.
Volgens https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
465 (TCP): Authenticated SMTP[10] over TLS/SSL (SMTPS)
Maar als ik even vluchtig om me heen kijk....Mijn eerste indruk is bijv. dat Ziggo na ca. 1 3/4 jaar nog steeds geen SMTPS over port 465 voor mekaar heeft,
gelet op hun instructies op het web. Google mail schijnt bijv. wel SMTPS aan te kunnen, ja zelfs ook MTA-STS:
https://www.security.nl/posting/604969/Gmail+eerste+grote+provider+die+MTA-STS-standaard+ondersteunt
Mijn vragen zijn:
1. Ken je NL-emailproviders die SMTPS (ca. 1 3/4 jaar na dato ...) wél hebben geïmplementeerd of er serieus mee bezig zijn, of loopt Nederland weer achter de feiten aan?
2. Nog nuttige op- of aanmerkingen over dit onderwerp?
mvg, Anno.
Reacties (10)
Ja ik ken ze.
Moest in PHP een custom library maken met detectie functionaliteit omdat een aantal providers er een soepje van maakte.
Bijvoorbeeld zeggen dat je TLS 1.2 gebruikt, maar mijn mailer crashte omdat 465 alkeen TLS 1.0 ondersteunde.
Moest in PHP een custom library maken met detectie functionaliteit omdat een aantal providers er een soepje van maakte.
Bijvoorbeeld zeggen dat je TLS 1.2 gebruikt, maar mijn mailer crashte omdat 465 alkeen TLS 1.0 ondersteunde.
Gebruik van poort 465 icm TLS is "deprecated". Dat zul je dus niet vaak zien in producten die officiele standaards
willen ondersteunen.
willen ondersteunen.
"het STARTTLS-commando niet door een man-in-the-middle van de lijn wordt "weggestript"
(zodat het nooit aankomt bij de emailserver, en deze er dus ook niet adequaat op kan reageren)"
Daarnaast kan iedereen een certificaat kan genereren, een succesvolle MitM operatie is vrijwel gegarandeerd. De meeste mail servers vinden alles goed. STARTTLS beschermd dan enkel tegen opportunistisch packet sniffing door een amateur snuffelaar.
Het kan alleen als er je meer maatregelen treft: een certificaat, DNSSEC, DANE en CAA in DNS en dit afdwingen als standaard setting. De rest deferren, niet aannemen of voorzien van een waarschuwing.
Behalve in Nederland (dankzij de overheid!) is het oorverdovend stil op het gebied van DANE. Elke browser en mail server zou dat absoluut moeten ondersteunen. Maar het gebeurt niet. In plaats daarvan stuurt bijvoorbeeld Firefox al je DNS traffic over HTTPS naar Cloudflare [facepalm].
(zodat het nooit aankomt bij de emailserver, en deze er dus ook niet adequaat op kan reageren)"
Daarnaast kan iedereen een certificaat kan genereren, een succesvolle MitM operatie is vrijwel gegarandeerd. De meeste mail servers vinden alles goed. STARTTLS beschermd dan enkel tegen opportunistisch packet sniffing door een amateur snuffelaar.
Het kan alleen als er je meer maatregelen treft: een certificaat, DNSSEC, DANE en CAA in DNS en dit afdwingen als standaard setting. De rest deferren, niet aannemen of voorzien van een waarschuwing.
Behalve in Nederland (dankzij de overheid!) is het oorverdovend stil op het gebied van DANE. Elke browser en mail server zou dat absoluut moeten ondersteunen. Maar het gebeurt niet. In plaats daarvan stuurt bijvoorbeeld Firefox al je DNS traffic over HTTPS naar Cloudflare [facepalm].
10:48 door Anoniem: Gebruik van poort 465 icm TLS is "deprecated". Dat zul je dus niet vaak zien in producten die officiele standaards willen ondersteunen.
VROEGÂH ja.Maar het is inmiddels n.a.v. RFC 8314 in ere herstelt om o.a. te kunnen worden gebruikt voor SMTPS-mail (TCP).
Dit had je kunnen weten als je de aangegeven link even had gelezen en daarin de details voor poort 465 had opgezocht:
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
11:26 door Anoniem:Daarnaast kan iedereen een certificaat kan genereren, een succesvolle MitM operatie is vrijwel gegarandeerd. De meeste mail servers vinden alles goed. STARTTLS beschermd dan enkel tegen opportunistisch packet sniffing door een amateur snuffelaar.
Er worden eisen gesteld aan mailclients om dit soort man-in-the-middle attacks te voorkomen: https://tools.ietf.org/html/rfc7817#page-3 (paragraaf 3)
Met een standaard TLS verbinding met je mailserver heb je geen STARTTLS meer nodig.
Het kan alleen als er je meer maatregelen treft: een certificaat, DNSSEC, DANE en CAA in DNS en dit afdwingen als standaard setting.
Ja? En? Dus...? Kan zoiets niet of zo? Of moeten we het zien als iets dat je even onder de aandacht wilt brengen voordat iemand het vergeet?Behalve in Nederland (dankzij de overheid!) is het oorverdovend stil op het gebied van DANE. Elke browser en mail server zou dat absoluut moeten ondersteunen. Maar het gebeurt niet. In plaats daarvan stuurt bijvoorbeeld Firefox al je DNS traffic over HTTPS naar Cloudflare [facepalm].
Als Cloudflare DoH je niet bevalt dan zet je het toch lekker uit.https://support.mozilla.org/en-US/kb/firefox-dns-over-https en scroll naar de paragraaf "Enabling and disabling DNS-over-HTTPS".
Verder uit 2017 (nog van vóór het uitkomen van RFC8314):
https://www.security.nl/posting/508294/NCSC+adviseert+STARTTLS+en+DANE+voor+mailservers.
De link hierin naar de .pdf van het NCSC is inmiddels gewijzigd. Men kan nu het beste kijken op:
https://www.ncsc.nl/documenten/factsheets/2019/juni/01/factsheet-beveilig-verbindingen-van-mailservers
Voor wat betreft de overheid: https://www.forumstandaardisatie.nl/standaard/starttls-en-dane
Als jij denkt dat je wat nuttigs hebt te melden over dat onderwerp dan kan je misschien contact opnemen met de aldaar genoemde Bart K. en voorleggen wat je op je hart hebt?
In browsers is overigens wel ondersteuning aanwezig voor Certificate Transparency en DNS Certification Authority Authorization, hetgeen soortgelijke problemen oplost als DANE. Om redenen vermeld in https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities ondersteunen Chrome en Firefox browsers standaard geen DANE.
(er bestaat wel een addon die je zou kunnen installeren als het je wat lijkt)
@Vandaag, 16:51 door Anoniem
Er bestaan geen werkende addons voor DANE voor firefox. CAA heeft geen certificate signing en dus geen vergelijkbare beveiliging, het is een toevoeging aan DANE en zeker geen vervanger. DANE verbindt een certificaat met DNS die weer beschermd wordt door DNSSEC. Voorlopig is CAA checking sinds een paar jaar alleen verplicht voor CA's, niet voor browsers of mailers. Beide methoden zullen securitybewuste domeineigenaren implementeren. Browser en mail client developers zouden het ook moeten ondersteunen.
CAA is dus vooral voor CA's, het is niet effectief voor gebruikers. Op zichzelf garandeert CAA vooralsnog weinig. Het doet niets tegen gestolen of illegaal gegenereerde certifcaten. Komodo had de eer om CAA te negeren nadat het verplicht werd..
Zoals gezegd, veel beter dan je privacy in handen geven van een bulletproof hoster of privacyschender.
Er bestaan geen werkende addons voor DANE voor firefox. CAA heeft geen certificate signing en dus geen vergelijkbare beveiliging, het is een toevoeging aan DANE en zeker geen vervanger. DANE verbindt een certificaat met DNS die weer beschermd wordt door DNSSEC. Voorlopig is CAA checking sinds een paar jaar alleen verplicht voor CA's, niet voor browsers of mailers. Beide methoden zullen securitybewuste domeineigenaren implementeren. Browser en mail client developers zouden het ook moeten ondersteunen.
CAA is dus vooral voor CA's, het is niet effectief voor gebruikers. Op zichzelf garandeert CAA vooralsnog weinig. Het doet niets tegen gestolen of illegaal gegenereerde certifcaten. Komodo had de eer om CAA te negeren nadat het verplicht werd..
Zoals gezegd, veel beter dan je privacy in handen geven van een bulletproof hoster of privacyschender.
Er bestaan geen werkende addons voor DANE voor firefox.
Kan zijn hoor, maar er was altijd wel iets. Lees:https://tutanota.com/blog/posts/dane-how-to-browser-plugins/
CAA heeft geen certificate signing en dus geen vergelijkbare beveiliging, het is een toevoeging aan DANE en zeker geen vervanger. DANE verbindt een certificaat met DNS die weer beschermd wordt door DNSSEC. Voorlopig is CAA checking sinds een paar jaar alleen verplicht voor CA's, niet voor browsers of mailers. Beide methoden zullen securitybewuste domeineigenaren implementeren. Browser en mail client developers zouden het ook moeten ondersteunen.
CAA streeft samen met CT (Certificate Transparency) hetzelfde doel na als DANE, namelijk het voorkomen van fraude via fake websites d.m.v. valse certificaten.DANE is overigens niet perfect. Het werkt alleen als DNSSEC altijd toegankelijk is voor alle gebruikers wereldwijd,
en dit levert bij elkaar veel extra netwerkverkeer op. En waarom zou DNSSEC nooit eens plat liggen? Wat dan?
Er zitten bezwaarlijke kanten aan het gebruik van DANE (dan wel aan DNSSEC waar DANE gebruik van maakt) in browsers. Lees dit maar eens: https://www.imperialviolet.org/2015/01/17/notdane.html
Wie toch DNSSEC wil, kan overigens terecht bij.... Cloudflare!...
https://blog.cloudflare.com/one-click-dnssec-with-cloudflare-registrar/
(maar dan wil je vast geen DANE/DNSSEC meer?... ;)
CAA bepaalt welke CAs certificaten mogen verstrekken voor welk domein. Het is een onderdeel van het helpen voorkomen van fraude met websites en valse certificaten, omdat een hacker dankzij CAA niet gemakkelijk bij iedere lousy CA terecht kan voor een perfect namaakcertificaat tbv websitevervalsing en oplichting. (uitzonderingen bevestigen de regel)
En omdat CAA niet helemaal perfect is, is er ook nog CT om frauduleuze of per ongeluk toch uitgeven certificaten op te sporen terwijl dat niet mocht. https://web.archive.org/web/20190808221646/https://blog.cloudflare.com/introducing-certificate-transparency-monitoring/
SMTPS is email-transport via een TLS-verbinding, en vergelijkbaar met een https-verbinding tussen browser en website,
inclusief omgang met certificaten en scherpe controle van certificaten door de mailclient zoals dit ook bij browsers het geval is. In zijn simpelste vorm log je gewoon in met username/wachtwoord zoals gewoonlijk. Dit gaat TLS-encrypted over de lijn, evenals de mails. Een client-certificaat zou ook kunnen, maar is alleen noodzakelijk in situaties waarbij authenticatie met usernaam/wachtwoord onvoldoende is.
Een veel groter nadeel van DANE is dat het een kruislingse afhankelijkheid introduceert in je beheer.
Als je het certificaat op een service vernieuwt moet je een DNS entry (een andere service) corresponderend aanpassen.
Dat is hardstikke lastig, zeker als dat vernieuwen van certificaten automatisch gebeurt (letsencrypt!) en je DNS service
geen specifieke API bevat die het toelaat om een DANE record te wijzigen en verder niks.
Moet dat via een algemene API dan introduceer je weer extra risico's dat je DNS door een remote attack kan worden
aangepast.
Er zou een soort modus moeten zijn waarin de DNS service als een soort van proxy voor het valideren van het
certificaat kan werken. Zodat die bij een DANE query via een of ander secure kanaal kan navragen wat op dit moment
het geldige certificaat is, ipv van dat dat in de DNS service zelf moet worden vastgelegd.
Als je het certificaat op een service vernieuwt moet je een DNS entry (een andere service) corresponderend aanpassen.
Dat is hardstikke lastig, zeker als dat vernieuwen van certificaten automatisch gebeurt (letsencrypt!) en je DNS service
geen specifieke API bevat die het toelaat om een DANE record te wijzigen en verder niks.
Moet dat via een algemene API dan introduceer je weer extra risico's dat je DNS door een remote attack kan worden
aangepast.
Er zou een soort modus moeten zijn waarin de DNS service als een soort van proxy voor het valideren van het
certificaat kan werken. Zodat die bij een DANE query via een of ander secure kanaal kan navragen wat op dit moment
het geldige certificaat is, ipv van dat dat in de DNS service zelf moet worden vastgelegd.
@11:40 door Anoniem
Je kunt meerdere DNS records aanhouden. Met een script kun je zorgen dat er tijd zit tussen het opvragen van het certificaat en het gebruik. Zodoende kun je een gladde overgang maken. Er zijn diverse oplossingen bedacht.
Willekeurig voorbeeldje: https://blog.hansenpartnership.com/using-letsencrypt-certificates-with-dane/
@ 19:49 door Anoniem
Een armchair onderzoekje als dat van jou met alleen Google search en vooringenomen standpunten, slecht lezen, slecht refereren, slecht begrip en flamend reageren levert geen nuttig inzicht op. Het werkt zoals ik beschreef in @ 00:56 door Anoniem.
Je kunt meerdere DNS records aanhouden. Met een script kun je zorgen dat er tijd zit tussen het opvragen van het certificaat en het gebruik. Zodoende kun je een gladde overgang maken. Er zijn diverse oplossingen bedacht.
Willekeurig voorbeeldje: https://blog.hansenpartnership.com/using-letsencrypt-certificates-with-dane/
@ 19:49 door Anoniem
Een armchair onderzoekje als dat van jou met alleen Google search en vooringenomen standpunten, slecht lezen, slecht refereren, slecht begrip en flamend reageren levert geen nuttig inzicht op. Het werkt zoals ik beschreef in @ 00:56 door Anoniem.
Door Anoniem: @11:40 door Anoniem
Je kunt meerdere DNS records aanhouden. Met een script kun je zorgen dat er tijd zit tussen het opvragen van het certificaat en het gebruik. Zodoende kun je een gladde overgang maken. Er zijn diverse oplossingen bedacht.
Willekeurig voorbeeldje: https://blog.hansenpartnership.com/using-letsencrypt-certificates-with-dane/
@ 19:49 door Anoniem
Een armchair onderzoekje als dat van jou met alleen Google search en vooringenomen standpunten, slecht lezen, slecht refereren, slecht begrip en flamend reageren levert geen nuttig inzicht op. Het werkt zoals ik beschreef in @ 00:56 door Anoniem.
De waarheid moet verifieerbaar zijn om hem overtuigend te maken, dus ik gaf steeds enkele links erbij.Je kunt meerdere DNS records aanhouden. Met een script kun je zorgen dat er tijd zit tussen het opvragen van het certificaat en het gebruik. Zodoende kun je een gladde overgang maken. Er zijn diverse oplossingen bedacht.
Willekeurig voorbeeldje: https://blog.hansenpartnership.com/using-letsencrypt-certificates-with-dane/
@ 19:49 door Anoniem
Een armchair onderzoekje als dat van jou met alleen Google search en vooringenomen standpunten, slecht lezen, slecht refereren, slecht begrip en flamend reageren levert geen nuttig inzicht op. Het werkt zoals ik beschreef in @ 00:56 door Anoniem.
Dit "verifieerbaar zijn" ontbreekt er bij jou aan. Blijkbaar redeneer je nogal veel vanuit eigen mening en eigen inzicht.
De waarheid omtrent DANE is dat het allemaal niet zo zwart/wit en perfect is als je schijnt te denken.
Ik heb geprobeerd duidelijk te maken waarom DANE niet het ei van Columbus is. Aan iedere mogelijke oplossing zitten meestal voordelen en nadelen en bijkomende aspecten die meewegen. Je kunt er dus vanuit gaan dat browsermakers niet voor niets NIET voor DANE hebben gekozen. Ze hebben gekozen voor het alternatief CAA (i.c.m. CT) om op een praktische manier en zonder de nadelen van DANE toch een vrij goede security te kunnen bieden voor wat certificaten betreft. En het is maar zeer de vraag of ze ooit reden krijgen om terug te keren naar DANE. Zie:
https://newsbeezer.com/germanyeng/dnssec-string-dane-for-browsers-is-practically-dead/ (mei 2019)
Ik herhaal: DANE for browsers is practically dead.
(Terugblik DANE vs CAA, 2 jaar geleden:
https://www.farsightsecurity.com/txt-record/2017/08/25/stsauver-caa-records-farsight/ (aug.2017) )
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?