Network Security: Email and Domain Name System PDF

Network Security XI. Electronic Mail and Domain Name System Prof. Dr. Torsten Braun, Institut für Informatik Bern, 25.11.2024 – 02.12.2024 Network Security: Electronic Mail and Domain Name System Electronic Mail Table of Contents 1. Internet Mail Architecture 6. Domain Name System Security 2. Email Formats 7. DNS-based Authentication of Named Entities 3. Email Threats 4. Pretty Good Privacy 8. Sender Policy Framework 5. Secure/Multipurpose 9. Domain Keys Identified Mail Internet Mail Extensions 10. Domain-based Message Authentication, Reporting, and Conformance 3 Network Security: Electronic Mail and Domain Name System 1. Internet Mail Architecture 1. Email Protocols and Modules - Message User Agent - operates on behalf of user actors and user applications. - formats message and performs initial submission into MHS via MSA. - processes received mail for storage and/or display to the recipient user. - Mail Submission Agent - accepts message submitted by MUA. - enforces policies of hosting domain. - Message Transfer Agent - relays mail for one application-level hop. - adds trace information to message header. - Mail Delivery Agent - transfers message from Message Handling System to Message Store. - Message Store - An MUA can employ a long-term MS. - MS can be located on a remote server or on same machine as MUA. - Typically, MUA retrieves messages from a remote server using Post Office Protocol or Internet Message Access Protocol. 4 Network Security: Electronic Mail and Domain Name System 1. Internet Mail Architecture 2.1 Simple Mail Transfer Protocol - Direct TCP connections between servers Commands between client and server - Transmission of multiple messages over a - HELO: introduction TCP connection in both directions - MAIL FROM: sender - Messages - RCPT TO: receiver - ASCII text only - Maximum message length < 64 KB - DATA: message data in older implementations - QUIT: end - Message formats - RFC822 (Text) - Multipurpose Internet Mail Extensions 5 Network Security: Electronic Mail and Domain Name System 1. Internet Mail Architecture 2.2 SMTP Operation % telnet asterix 25 Trying 130.92.64.4... Connected to asterix. Escape character is '^]'. 220 asterix.iam.unibe.ch Sendmail SMI-8.6/SMI-SVR4 ready at Fri, 20 Feb 1998 12:40:16 +0100 HELO iam.unibe.ch 250 asterix.iam.unibe.ch Hello akela [130.92.65.44], pleased to meet you MAIL FROM: 250... Sender ok RCPT TO: 250... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Hallo Torsten.. 250 MAA00591 Message accepted for delivery QUIT 221 asterix.iam.unibe.ch closing connection Connection closed by foreign host. % 6 Network Security: Electronic Mail and Domain Name System 1. Internet Mail Architecture 3. Client Protocols Post Office Protocol Internet Mail Access Protocol - allows an email client to - enables email client to access download an email from an email on email server. email server. - TCP port 143 - POP3 UA connects to server - more complex than POP3 via TCP, TCP port 110 - provides stronger authentication - After authorization, UA can and provides other functions not issue POP3 commands to supported by POP3. retrieve and delete mail. 7 Network Security: Electronic Mail and Domain Name System 2. Email Formats 1.1 RFC 822/5322 Format Message-ID: More header fields - Bcc: Date: Fri, 20 Feb 1998 21:16:13 +0100 From: Torsten Braun - Reply-To: - In-Reply-To: To: [email protected] Header Subject: Hallo Cc: [email protected] Body Hello Torsten. 8 Network Security: Electronic Mail and Domain Name System 2. Email Formats 1.2 SMTP/RFC 5322 Limitations SMTP - cannot transmit executable files or other binary objects. - cannot transmit text data that includes national language characters. - servers may reject mail message over a certain size. 9 Network Security: Electronic Mail and Domain Name System 2. Email Formats 2.1 MIME Specifications - New message header fields - Transfer encodings enable - Definition of content formats conversion of any content standardizing representations format into a form that is that support multimedia email protected from alteration by the mail system 10 Network Security: Electronic Mail and Domain Name System 2. Email Formats 2.2 MIME-Mail Message-ID: --------------5EF727B907217426DF5C4EE0 Content-Type: text/html; charset=us-ascii Date: Fri, 20 Feb 1998 22:22:10 +0100 Content-Transfer-Encoding: 7bit From: Torsten Braun Hello Torsten. MIME-Version: 1.0   To: [email protected] --------------5EF727B907217426DF5C4EE0 Subject: MIME Beispiel Content-Type: text/plain; charset=us-ascii; Content-Type: multipart/mixed; name="test.txt" boundary= Content-Transfer-Encoding: 7bit "------------5EF727B907217426DF5C4EE0" Content-Disposition: inline; This is a multipart message in mime filename="test.txt" format. Testdatei 11 --------------5EF727B907217426DF5C4EE0-- Network Security: Electronic Mail and Domain Name System 2. Email Formats 2.3 MIME Header Fields mandatory optional - MIME-Version: 1.0: indicates that - Content-ID identifies MIME entities message conforms to RFCs 2045/2046. uniquely in multiple contexts. - Content-Type describes data contained - Content-Description is a text in the body with sufficient detail that the receiving user agent can select an description of the object with the body; appropriate agent or mechanism to this is useful when the object is not represent the data to the user readable (e.g., audio data). - Content-Transfer-Encoding indicates the type of transformation that has been used to represent the body of the message in a way that is acceptable for mail transport. 12 Network Security: Electronic Mail and Domain Name System 2. Email Formats 2.4 MIME Content Types and Transfer Encodings 13 Network Security: Electronic Mail and Domain Name System 3. Email Threats 1. Classification - Authenticity - Integrity - Confidentiality - Availability related 14 Network Security: Electronic Mail and Domain Name System 3. Email Threats 2.1 Email Threats and Mitigations Impact on Purported Threat Impact on Receiver Mitigation Sender Email sent by unauthorized MTA in enterprise, Unsolicited Bulk Email e.g., malware botnet and/or email containing malicious links may be Email message sent delivered into user using spoofed or Loss of reputation, valid Deployment of domain- inboxes unregistered sending email from enterprise based authentication domain may be blocked as techniques. Use of possible spam/phishing UBE and/or email digital signatures over Email message sent attack. email. containing malicious using forged sending links may be delivered. address or email Users may address, inadvertently divulge i.e., phishing, spear 15 sensitive information or Network Security: Electronic Mail and Domain Name System 3. Email Threats 2.2 Email Threats and Mitigations Impact on Purported Threat Impact on Receiver Mitigation Sender Email modified in transit Use of TLS to encrypt Leak of sensitive Leak of sensitive email transfer between information or information, altered Disclosure of sensitive server. Personally Identifiable message may contain information (e.g., PII) Use of end-to-end email Information. malicious information via monitoring and encryption. capturing of email traffic UBE and/or email None, unless purported containing malicious Techniques to address UBE (i.e., spam) sender is spoofed. links may be delivered UBE. into user inboxes 16 Network Security: Electronic Mail and Domain Name System 3. Email Threats 3.1 Counter Threat Protocols - STARTTLS - DNS Security Extensions - SMTP security extension that - provides authentication and provides authentication, integrity, integrity protection of DNS data. non-repudiation, confidentiality for the entire SMTP message by - DNS-based Authentication of running SMTP over TLS Named Entities - overcomes problems in the - S/MIME Certificate Authority system by - provides authentication, integrity, providing an alternative channel non-repudiation, confidentiality of for authenticating public keys the SMTP message body. based on DNSSEC. 17 Network Security: Electronic Mail and Domain Name System 3. Email Threats 3.2 Counter Threat Protocols - Sender Policy Framework - Domain Keys Identified Mail - uses DNS to allow domain owners - enables an MTA to sign selected headers and to create records that associate the body of a message. domain name with a specific IP - validates the source domain of the mail and address range of authorized provides message body integrity. message senders. - Receivers check the SPF TXT - Domain-based Message Authentication, record in DNS to confirm that the Reporting, and Conformance purported sender of a message is - informs senders about the proportionate permitted to use that source IP effectiveness address and reject mail that does of their SPF and DKIM policies not come from an authorized IP - signals to receivers what action address. should be taken in various individual and bulk attack scenarios 18 Network Security: Electronic Mail and Domain Name System 3. Email-Threats 3.3 Interrelationship of Counter Threat Protocols 19 Network Security: Electronic Mail and Domain Name System 4. Pretty Good Privacy Example Email From: Michael Elkins To: Michael Elkins Mime-Version: 1.0 Content-Type: multipart/encrypted; boundary=foo; protocol="application/pgp-encrypted“ --foo Content-Type: application/pgp-encrypted Version: 1 --foo Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- Version: 2.6.2 hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3 1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8= =zzaA -----END PGP MESSAGE----- --foo-- 20 Network Security: Electronic Mail and Domain Name System 5. Secure/Multipurpose Internet Mail Extensions 1. S/MIME and PGP - PGP - is based on «Web of Trust»: trusted third parties can certify keys, useful rather for closed groups. - S/MIME - is based on hierarchical CA system similar to TLS. - PGP and S/MIME - use different cryptographic schemes. - are not compatible. 21 Network Security: Electronic Mail and Domain Name System 5. Secure/Multipurpose Internet Mail Extensions 2. Services 22 Network Security: Electronic Mail and Domain Name System 5. Secure/Multipurpose Internet Mail Extensions 3. Authentication by means of a digital signature 1. The sender creates a message. 2. SHA-256 is used to generate a 256-bit message digest of the message. 3. Message digest is encrypted with RSA using the sender’s private key, result is appended to the message as well as the identifying information for the signer, which will enable the receiver to retrieve the signer’s public key. 4. Receiver uses RSA with the sender’s public key to decrypt and recover message digest. 5. Receiver generates a new message digest for the message and compares it with the decrypted hash code. If both match, the message is accepted as authentic. 23 Network Security: Electronic Mail and Domain Name System 5. Secure/Multipurpose Internet Mail Extensions 4. Confidentiality S/MIME confidentiality by encrypting messages. Operation Sequence - Mostly: AES with a 128-bit key using CBC 1. Sender generates a message and a random mode 128-bit number to be used as a content- encryption key for this message only. - Key is also encrypted, typically with RSA 2. Message is encrypted using the - Each symmetric key content-encryption key. (content-encryption key) 3. Content-encryption key is encrypted with is used only once. RSA using the recipient’s public key and is attached to the message. 4. Receiver uses RSA with its private key to decrypt and recover content-encryption key. 5. Content-encryption key is used to decrypt 24 message. Network Security: Electronic Mail and Domain Name System 5. Secure/Multipurpose Internet Mail Extensions 4.1 Encryption and Authentication 25 Network Security: Electronic Mail and Domain Name System 5. Secure/Multipurpose Internet Mail Extensions 4.2 Decryption and Authentication 26 Network Security: Electronic Mail and Domain Name System 5. Secure/Multipurpose Internet Mail Extensions 5.1 S/MIME Message Content Types (RFC 5652) - Data - CompressedData - refers to inner MIME-encoded - used to apply data compression to a message content, which may then message be encapsulated in a SignedData, - Clear signing EnvelopedData, or - A digital signature is calculated for a CompressedData content type MIME-encoded message and the two - EnvelopedData parts (message and signature) form a - consists of encrypted content of multipart MIME message any type and encryption keys for - can be read and their signatures one or more recipients verified by email entities that do not implement S/MIME - SignedData - For most cases: result of security - used to apply a digital algorithm will be arbitrary binary data signature to a message → base64 27 Network Security: Electronic Mail and Domain Name System 5. Secure/Multipurpose Internet Mail Extensions 5.2 Enveloped Data 1. Generate a pseudorandom session key for a Content-Type: application/pkcs7-mime; particular symmetric encryption algorithm smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 2. For each recipient, encrypt the session key with the recipient’s public RSA key. Content-Disposition: attachment; filename=smime.p7m 3. For each recipient, prepare a block known rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF as RecipientInfo containing 467GhIGfHfYT6 - identifier of recipient’s 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnj public-key certificate T6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6g - identifier of the algorithm used hyHhHUujpfyF4 to encrypt the session key 0GhIGfHfQbnj756YT64V - encrypted session key 4. Encrypt message content with 28 session key. Network Security: Electronic Mail and Domain Name System 5. Secure/Multipurpose Internet Mail Extensions 5.3 Signed Data 1. Select message digest algorithm Content-Type: application/pkcs7-mime; (SHA or MD5). smime-type=signed-data; name=smime.p7m 2. Compute message digest Content-Transfer-Encoding: base64 of content to be signed. Content-Disposition: attachment; 3. Encrypt message digest filename=smime.p7m with signer’s private key. 567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9H 4. Prepare a block known as SignerInfo G4VQbnj7 containing 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhH UujhJhjH - signer’s public-key certificate HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8 - identifier of message digest algorithm HHGghyHh - identifier of algorithm used to 6YT64V0GhIGfHfQbnj75 encrypt the message digest - encrypted message digest. 29 Network Security: Electronic Mail and Domain Name System 5. Secure/Multipurpose Internet Mail Extensions 5.4 Clear Signing - achieved using multipart content Content-Type: multipart/signed; protocol=”application/pkcs7- signature”; micalg=sha1; type with signed subtype boundary=boundary42 - Signing process does not involve —boundary42 transforming the message to be Content-Type: text/plain This is a clear-signed message. signed. —boundary42 - Recipients with MIME Content-Type: application/pkcs7-signature; name=smime.p7s but not S/MIME capability Content-Transfer-Encoding: base64 can read incoming message. Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 —boundary42— 30 Network Security: Electronic Mail and Domain Name System 5. Secure/Multipurpose Internet Mail Extensions 6.1 Certificate Processing - S/MIME uses public-key certificates that conform to version 3 of X.509 - S/MIME managers and/or users must configure each client with a list of trusted keys and certificate revocation lists - The responsibility is local for maintaining the certificates needed to verify incoming signatures and to encrypt outgoing messages. - Certificates are signed by certification authorities. 31 Network Security: Electronic Mail and Domain Name System 5. Secure/Multipurpose Internet Mail Extensions 6.2 User Agent Role - Key generation - Registration - The user of some related - A user’s public key must be administrative utility registered with CA in order to receive - MUST be capable of an X.509 public-key certificate. generating separate DH and DSS key pairs. - Certificate storage and retrieval - SHOULD be capable of - A user requires access to a local list generating RSA key pairs. of certificates (to be maintained by user of administrative entity) in order to verify incoming signatures and to encrypt outgoing messages. 32 Network Security: Electronic Mail and Domain Name System 6. DNS Security 1.1 Domain Name System - Directory lookup service mapping Key features of DNS database are: the name of a host to its numeric IP - variable-depth hierarchy for names address - is used by MUAs and MTAs to find - distributed database the address of the next hop server for mail delivery - is based on a hierarchical database containing Resource Records that include name, IP address, and other information 33 about hosts Network Security: Electronic Mail and Domain Name System 6. DNS Security 1.2 DNS Name Resolution 34 Network Security: Electronic Mail and Domain Name System 6. DNS Security 1.3 DNS Resource Record Types 35 Network Security: Electronic Mail and Domain Name System 6. DNS Security 1.4 DNS Resource Records Server stores Resource Records Examples (Name, Value, Type, Class, (inf.unibe.ch, asterix.unibe.ch, NS, IN) Lifetime) (inf.unibe.ch, obelix.unibe.ch, MX, IN) (asterix.unibe.ch, 130.92.64.4, A, IN) (obelix.unibe.ch, 130.92.64.5, A, IN) (_http._tcp.inf.unibe.ch, 80 www.inf.unibe.ch, SRV, IN) 36 Network Security: Electronic Mail and Domain Name System 6. DNS Security 2.1 DNS Security Extensions - provide end-to-end protection by digital - consist of a set of new resource signatures that are created by record types and modifications to responding zone administrators and the existing DNS protocol. verified by a recipient’s resolver software. - are defined in RFCs 4033-4035. - avoid need to trust intermediate name servers and resolvers that cache or route the DNS records originating from the responding zone administrator before they reach the source of the query. 37 Network Security: Electronic Mail and Domain Name System 6. DNS Security 2.2 DNSSEC RRs 1. DNSKEY contains a public key - Asymmetric key pair exists for each zone. Private key is used for signatures. 2. Resource Record Digital Signature - associated with each Resource Record Set (RRs with same label, class, type) - When client requests data, RRset is returned with associated digital signature in RRSIG 3. NSEC: authenticated denial of existence record - To secure all DNS lookups, DNSSEC uses the NSEC RR to authenticate negative responses to queries. - NSEC is used to identify the range of DNS names or resource record types that do not exist among the sequence of domain names in a zone. 4. Delegation Signer - Hash of public key, stored on higher level - facilitates key signing and authentication between DNS zones to create an 38 authentication chain from the root of the DNS tree down to a specific domain name Network Security: Electronic Mail and Domain Name System 6. DNS Security 2.2.1 Operation - DNSSEC Operation Trust in the source’s public key - Data origin authentication ensures that data (for signature verification) is established originated from correct source. - Data integrity verification ensures that - not by going to a third party or a chain of content of a RR has not been modified. third parties (as in PKI chaining), - DNS zone administrator - but by starting from a trusted zone - digitally signs every Resource Record set in the zone, e.g., (such as the root zone) and establishing - www.example.org IN A 127.0.0.1 the chain of trust down to the current - www.example.org IN A 192.168.0.1 source of response through successive - publishes this collection of digital signatures, verifications of signature of the public key along with the zone administrator’s public of a child by its parent. key, in the DNS itself. 39 Network Security: Electronic Mail and Domain Name System 6. DNS Security Validating Server 2.2.2 Operation RRSet RRSet Zone File Hash RRSIG RRSet Hash Decryption with Fingerpri public key RRSIG nt Fingerpri Fingerpri Encryption with nt Comparison nt private key. DNSKEY Hash Verification RRSIG DS Parent Zone Record 40 Network Security: Electronic Mail and Domain Name System 7. DNS-based Authentication of Named Entities 1. Overview DANE - addresses the vulnerability of the use of CAs in a global PKI. - allows X.509 certificates, commonly used for TLS, to be bound to DNS names using DNSSEC. - is a way to authenticate TLS client and server entities without CA. - has been defined in RFC 6698. 41 Network Security: Electronic Mail and Domain Name System 7. DNS-based Authentication of Named Entities 2. TLS Authentication RR - can be used to securely - A server domain owner creates a authenticate TLS certificates. TLSA RR that identifies the - specifies that a service certificate and its public key. certificate or a CA can be - When a client receives an X.509 authenticated in the DNS itself. certificate in the TLS negotiation, - enables certificate issue and it looks up the TLSA RR for that domain and matches the TLSA delivery to be tied to a given data against the certificate as part domain. of the client’s certificate validation 42 procedure. Network Security: Electronic Mail and Domain Name System 7. DNS-based Authentication of Named Entities 3. DANE for SMTP - can be used in conjunction with SMTP over TLS, as provided by STARTTLS. - can authenticate the certificate of the SMTP server that the user’s MUA communicates with. - can also authenticate the TLS connections between SMTP MTAs. 43 Network Security: Electronic Mail and Domain Name System 8. Sender Policy Framework 1. Overview - SPF is way for a sending domain to identify and assert the mail senders for a given domain. - Problem: With the current email infrastructure, any host can use any domain name for each of the various identifiers in the mail header, not just the domain name where the host is located. Drawbacks of this approach: - It is difficult for mail handlers to filter out emails. - Entities can make use of email providers’ domain names, often with malicious intent. - RFC 7208 provides a protocol by which email providers can authorize hosts to use their domain names in the “MAIL FROM” or “HELO” identities. - Email providers publish SPF records in the DNS specifying which hosts are permitted to use their names - Mail receivers use published SPF records to test authorization of sending 44 MTAs using a given “HELO” or “MAIL FROM” identity during a mail transaction. Network Security: Electronic Mail and Domain Name System 8. Sender Policy Framework 2. Operation SPF checks a sender’s IP address against the policy encoded in any SPF record found at the sending domain. 45 Network Security: Electronic Mail and Domain Name System 8. Sender Policy Framework 3. Sender Side - A sending domain needs to - Mechanisms are used to identify all the senders for a define an IP address or range given domain and add that of addresses to be matched. information into the DNS as a - Modifiers indicate the policy separate resource record. for a given match. - Sending domain encodes the appropriate policy for each sender using the SPF syntax by using TXT RRs. 46 Network Security: Electronic Mail and Domain Name System 8. Sender Policy Framework 4. Receiver Side - If SPF is implemented at a - Alternatively, the entire message receiver, the SPF entity uses can be absorbed and buffered the SMTP envelope until all the checks are finished. MAIL FROM: address - In either case, checks must be domain and the IP address of completed before the mail the sender to query an SPF TXT message is sent to the end user’s RR. inbox. - SPF checks can be started before the body of the email 47 message is received. Network Security: Electronic Mail and Domain Name System 8. Sender Policy Framework 5. Mechanisms 48 Network Security: Electronic Mail and Domain Name System 8. Sender Policy Framework 6. Modifiers 49 Network Security: Electronic Mail and Domain Name System 9. Domain Keys Identified Mail 1. Overview - A specification for cryptographically signing e-mail messages, permitting a signing domain to claim responsibility for a message. - Message recipients can verify the signature by querying the signer’s domain to retrieve the appropriate public key and can confirm that the message was attested by a party in possession of the private key for the signing domain. - Target: spam email prevention - RFC 6376 50 Network Security: Electronic Mail and Domain Name System 9. Domain Keys Identified Mail 2. Functional Flow - Signing might be performed by MUA, MSA, or MTA. - Verifying might be performed by MTA, MDA, or MUA. - If the signature passes, reputation information is used to assess the signer and that information is passed to the message filtering system. - If signature fails or there is no signature using the author’s domain, information about signing practices related to the author can be retrieved remotely and/or locally, and that information is passed to the message filtering system. For example, if the sender (e.g., gmail) uses DKIM but no DKIM signature is present, then the message may be considered fraudulent. - Signature is inserted into the RFC 5322 message as an additional header entry, starting with the keyword DKIM-Signature. 51 Network Security: Electronic Mail and Domain Name System 10. Domain-based Message Authentication, Reporting, and Conformance 1. Overview Problem DMARC (RFC 7489) - Neither SPF nor DKIM include - allows email senders to specify a mechanism to tell receivers policy on how their mail should if SPF or DKIM are in use. be handled, the types of reports that receivers can send back, and the frequency those reports should be sent. - policies in DNS TXT records - works with DKIM and SPF. 52 Network Security: Electronic Mail and Domain Name System 10. DMARC 2. Functional Flow 53 Thanks a lot for your Attentation Prof. Dr. Torsten Braun, Institut für Informatik Bern, 25.11.2024 – 02.12.2024

Network Security: Email and Domain Name System PDF

Document Details

Tags

Related

Summary

Full Transcript