ფოსტა, რომელიც მიდის: ყველაფერი, რასაც internet.nl ამოწმებს, და რატომ

შედეგი

როგორ შეამოწმოთ კონფიგურაცია

internet.nl ნიდერლანდების მთავრობისა და ინტერნეტორგანიზაციების ჯგუფის უფასო შემოწმებაა. აქ მისი ორი ნაწილია მნიშვნელოვანი: ვებგვერდი და საფოსტო დომენი. თითოეული ტესტი ან წარმატებულია, ან ვერ გადის, და ორივეს შედეგები საჯაროა.

ave17.com-ის ტესტები თავად შეგიძლიათ გაუშვათ; სამუშაო გეგმა დათარიღებული შედეგების გამოქვეყნების განზრახვას აღწერს.

უნდა ვთქვათ, რას არ ნიშნავს შედეგი. ის კონფიგურაციას ზომავს და არა ქცევას: სრულყოფილი შედეგი ადასტურებს, რომ დომენის გაყალბება რთულია და მისი ფოსტა დაშიფრულად გადაეცემა. ის არაფერს ადასტურებს იმის შესახებ, პასუხობენ თუ არა ამ დომენის უკან მდგომი ადამიანები წერილებს.

ვინ გამოგზავნა

SPF, DKIM და DMARC გამოყენების თანმიმდევრობით

ეს სამი მექანიზმი ერთ კითხვას პასუხობს: ნამდვილად ამ დომენიდან მოვიდა თუ არა წერილი. მათ ჩვეულებრივ არასწორი თანმიმდევრობით ნერგავენ, ამიტომ ბევრ დომენს სამივე აქვს, მაგრამ მაინც შეიძლება გაყალბდეს.

SPF

ჩამოვლის მანქანებს, რომლებსაც დომენის სახელით ფოსტის გაგზავნა შეუძლიათ. იაფია, მაგრამ ცალკე სუსტია: წერილის გადაგზავნისას შემოწმება ვერ გადის, რადგან გადამგზავნი სიაში არ არის.

DKIM

თავად წერილს აწერს ხელს, ამიტომ გადაგზავნისასაც ნარჩუნდება. ორი გასაღებით ვაწერთ ხელს, RSA და Ed25519, რადგან ზოგ მიმღებს მეორე ჯერ არ ესმის და ჩვენ ერთის არჩევას არ ვამჯობინებთ.

DMARC

მიმღებს ეუბნება, რა გააკეთოს, თუ პირველი ორი შემოწმება ვერ გაივლის, და ამასთან ანგარიშს ითხოვს. ჩვენთან არის p=reject: წერილი უარყავით. უფრო რბილი პოლიტიკა თავაზიანი თხოვნაა, რომელსაც გამგზავნებისა უმრავლესობა უგულებელყოფს.

მუშა თანმიმდევრობაა ჯერ DKIM, შემდეგ SPF, შემდეგ DMARC დაკვირვების რეჟიმში, სანამ ანგარიშები დამშვიდდება, და ბოლოს reject. პირდაპირ reject-ზე გადასვლით ორგანიზაცია საჯაროდ იგებს, რომელი მისი სისტემა აგზავნიდა ფოსტას ისე, რომ არავინ იცოდა.

როგორ მოვიდა წერილი

დაშიფრა, რომლის მოხსნაც გზაზე არ შეიძლება

საფოსტო სერვერები ოცი წელია შესაძლებლობის შემთხვევაში დაშიფრას გვთავაზობენ. ეს ნიშნავს, რომ შუაში მყოფ თავდამსხმელს შეუძლია შეთავაზება მოშალოს და ორივე სერვერის ღია ტექსტზე გადასვლას უყუროს. არც ერთი მხარე ამას ვერ ამჩნევს. ორი მექანიზმი ამ შესაძლებლობას კეტავს და სწორედ ეს ორი აკლია დომენების უმრავლესობას.

MTA-STS

HTTPS-ით მიწოდებული პოლიტიკა: "ამ ჰოსტის სახელებთან ყოველთვის გამოიყენეთ TLS; თუ ვერ ხერხდება, არ მიიტანათ". მას enforce რეჟიმში ვაქვეყნებთ, რომელიც ერთადერთი მოქმედი რეჟიმია.

DANE

მიმღების მოსალოდნელი სერტიფიკატი DNS-ში ქვეყნდება და DNSSEC-ით იწერება, რათა გამგზავნმა სერვერმა სერტიფიკატი დომენთან შეამოწმოს და არა სერტიფიცირების ორგანოების სიასთან. TLSA ჩანაწერებს ვაქვეყნებთ submission, submissions, IMAPS-ზე და თავად ფოსტის გაცვლის სერვერზე.

DNSSEC

თავად DNS პასუხების ხელმოწერები. მათ გარეშე ზემოთ ყოველი ჩანაწერი განცხადებაა, რომლის შეცვლაც თავდამსხმელს გადაცემის დროს შეუძლია. ამიტომ მოითხოვს DANE DNSSEC-ს და ამიტომ არის ჩვენი ყველა ზონა ხელმოწერილი.

MTA-STS და DANE განზრახ ფარავენ ერთმანეთს. პირველის დანერგვა მარტივია და ვებსერტიფიკატების სისტემას ენდობა; მეორე უფრო რთულია და DNSSEC-ს ენდობა. ორივე მექანიზმის მქონე დომენი დაცულია, რომელ სისტემასაც არ უნდა მისწვდეს თავდამსხმელი.

ვებნაწილი

რას მოითხოვს საიტის შემოწმება

იგივე ტესტის ვებნაწილი ძირითადად იმავე იდეას ამოწმებს: კავშირის დაცვის დონის დაწევა და სერტიფიკატის შეცვლა შეუძლებელი უნდა იყოს.

• IPv6 საიტზე და მისი სახელების სერვერებზე, ხელმისაწვდომი და იმავე შინაარსის მქონე, რაც IPv4
• DNSSEC ზონაზე, რათა თავად მისამართი ვერ შეიცვალოს
• HTTPS თანამედროვე შიფრებით, HSTS-ით და დაცვის დონის დაწევის გზის გარეშე
• DANE ვებსერტიფიკატზეაც, რასაც თითქმის არავინ აკეთებს
• დახურული CAA, რათა დომენის სერტიფიკატი მხოლოდ ჩვენ მიერ დასახელებულმა ორგანომ გასცეს
• უსაფრთხოების სათაურები, რომლებიც გვერდის უცხო ჩარჩოში ჩასმასა და მისი შინაარსის ტიპის არასწორად ამოცნობას აჩერებს

ორი მნიშვნელოვანი საკითხი

სად შეიძლება შედეგმა შეცდომაში შეგიყვანოთ

პირველი: DMARC p=reject-ით დომენზე, რომელიც ფოსტას არასოდეს აგზავნის, ტრივიალურია. ნამდვილი ფოსტის მქონე დომენი აქამდე მხოლოდ ანგარიშების რამდენიმე კვირა კითხვის შემდეგ მიდის. შედეგი იგივეა, სამუშაო სრულიად განსხვავებული. თუ ამ რიცხვით მიმწოდებლებს ადარებთ, ჰკითხეთ, ამ ორიდან რომელი გააკეთეს.

მეორე: DANE მიმღები მხარის შემოწმებას მოითხოვს, რასაც მსოფლიოს დიდი ნაწილი არ აკეთებს. მისი გამოქვეყნება შემმოწმებელი მიმღებების შემთხვევაში გიცავთ და დანარჩენებთან არაფერს გახარჯვინებთ, მაგრამ არ არის გარანტია, რომ ნებისმიერი კონკრეტული წერილი დაშიფრულად გადაეცა. ამას ვერავინ დაგპირდებათ.

და კიდევ ერთი, არა ხრიკი, უბრალოდ უხერხული: ეს ვერ აჩერებს დამაჯერებელ წერილს თქვენს მსგავსი დომენიდან. ეს სხვა პრობლემაა, რომელსაც ადამიანები პასუხობენ და არა ჩანაწერები.

რა დაჯდა

გულწრფელად

პირველ დომენზე ჩანაწერების გასამართად ერთი დღე და დანარჩენებზე თითოეულზე დაახლოებით ოცი წუთი, რადგან შემდეგ უკვე შაბლონი გვაქონდა. ნამდვილ დროს კონფიგურაცია არ ითხოვს: ის DMARC ანგარიშების ორი კვირა კითხვას მიაქვს, სანამ reject-ზე უსაფრთხოდ გადავალთ. ამ ნაწილის ყიდვა ან დაჩქარება არ შეიძლება.

ამას ჩვენ თავად ვმართავთ და არა საფოსტო მიმწოდებლის მეშვეობით, ამიტომ შეგვიძლია მისი აღწერა. თუ სხვანაირად გირჩევნიათ, ეს სრულიად გონივრულია; ზემოთ ჩამოვლილი ჩანაწერები მაინც ის არის, რაც თქვენს მიმწოდებელს უნდა მოსთხოვოთ.