3.3 data encrypting protocols Flashcards
Why we need pc-to-pc email encryption
- email transfers across the internet from one domain to another
- traditional vs modern way
- picture on page 79 and beyond
- Here is a generic example of the basics of email transfers across the internet from one internet domain to another
o Alice has type an email – from her address to Bob’s email address – Alice sends- note that Alice’s email program has the IP address of the @sans.org email server in its configuration
o Alice’s computer connects to the sans.org email server with a TCP port 25 connection the service simple mail transfer protocol
o The sans.org email server looks at the tp address of bob@giac.org and sends a query to its DNS server asking for the MX record of giac.org – in DNS, the MX record for each domain returns the IP address of that domain’s mmail server – therefore the DNS server returns the IP address of the giac.org mail server in this case
o Once the sans.org mail server has the IP address of the giac.org mail server, it establishes a TCP port 25 connection with that mail server, and the email transfers
o Once the email is on the giac.org mail server, it sits there paitently until Bob checks his email. When Bob does check email, his email software connects to the giac.org mail server on TCP port 110 and retrieves the email message
o This is the traditional way that email was invented – this connection is unencrypted and because gmail connects to a bunch of email servers everyday – if you are to authenticate then every mail server needs to know the username and password for every other mail server in the world – the encrypt and decryption can only happen if the key is on the same system, meaning every mail server in the world would need the keys of every other server in the world
o Today, many organizations implement a newer version of SMTP that offers password authentication and SSL/TLS-based encryption
o Likewise, when POP3 protocol first came out, there was no encryption. The protocol required password authentication, but the username and password passed across the wire in plaintext. Again, today, there are new versions of both POP3 that encrypt the data, including the password, using SSL/TLS encryption
o Note: in some instances you may find an authenticated and encrypted server-to-server communication, which is new but partner companies can exchange cryptographic certificates and set their servers up to authenticate and encrypt to each other – but even with that in place, the securky only happens between those two servers – more and more we are seeing opportunistic TLS encryption is used in the server-to-server communication – notice that the email would be in plaintext while on those servers, which is why it doesn’t solve the problem (the key point – when you don’t encrypt from alice to sans mail server it is still within your company, but when you send it to giac mail server, your data is on a public domain so you cannot protect patent and proprietary information unless you do end-to-end encryption – encrypting on the source computer and never decrypting until the destination computer, and if you do it that way, whether other steps in the connection are encrypted doesn’t even matter)
Secure multipurpose internet mail extensions (S/MIME)
- Transforms all email and attaches to 100% ASCII text for transition
- S/MIME: Lets MIME transform to ASCII
o Then encrypts the entire block of ASCII using hybrid cryptography
o Meaning both email test and attachments are encrypted
o On the receiving end, S/MIME decrypts everything and passes it back to MIME for translation back to its original form - S/MIME is built into Outlook and most other popular email clients
o Requires the use of digital certitificates to contain the keys
Email encryption: PGP/GPG
- Released by Phil Zimmerman in 1991 – first important email encryption capability
o Encrypts and digitally signs email and files/folders and whole disk
o Originally utilized PGP keys and still can
o Now supports certificates
Not true X.509 certificates; they have additional fields - First significant use of both crypto and signcryption – originally, you utilized PGP keys when using this software, those keys were stored on your hard drive in a public key ring, which were just files on your system containing the keys
- Now available in both freeware (GNU PGP or GPG) and commercial PGP now owned by Synmantec
o GPG is significantly harder to use than S/MIME or commercial PGP - OSI layer 7: only encrypts the data
Remote access and file transfer: Secure Shell (SSH)
- Command-line promprt on a computer somewhere else on the network – you enter commands on that distant computer and have them execute there
- The different is that telnet transmits all of your commands, their output, your username/password, and everything else across the network in cleartext. SSH encrypts all that information and also provides other functionality, such as file transfer
o Same functionality as Telnet though – difference is the encrypted connecition between the client and server, utilizes Diffie-hellman for secure key exchange
o Uses TCP Port 22 - Cases where organizations left their SSH keys laying around and attackers came in and got these to decrypt data – open source can help 2FA SSH keys
Secure transfer of data: SSL and TLS
- Secure Socket Layer (SSL) 1994: has been deprecated 2015 and should not be used, changed to transport layer security TLS v1.3 (2018)
- SSL was developed by Netscape, who maintained it until version 3 – Internet Engineering Task Force (IETF) improved SSL and renamed it to TLS – so TLS version 1 is actually SSL version 4
- Because SSL/TLS operated at the transport layer (OSI layer 4) you can actually encrypt any TCP-based protocol. Historically, the most common has been HTTP, but there is also an FTPS for encrypted file transfer and several others
- One of the most common misconceptions in IT today is that SSL and TLS run on TCP Port 444 – that is incorrect. SSL and TLS are transport layer protocols; port numbers are assigned only to application layer protocols. HTTPS uses port 443, but if you look at this slide, you can see FTPS Telners and several other have their own port numbers assignedto them
- Secure key exchange normally handled by Diffie-Hellman, Ellipticak Curve Diffie-Hellman, or RSA
Secure web: HTTPS
- HTTP-SSL or TLS encrypted:
o Encrypts all data between browser and web browser (both directions)
o Requires configuring server; no editing of web content is required
o Key exchange: Diffie-hellman or elliptical curve Diffie-hellman, but supports RSA - An OSI Layer 7 application: only encrypts data
o Usually operates on TCP port 443 - Common misunderstanding: HTTPS does not mean you’re encrypting something, but you’re only encrypting something if the server is properly configured – it’s rather rare now that the server is not configured properly
- Another common misunderstanding: HTTPS and TLS do not mean trust this – they mean that this is intended to private communication but you may be having private communication with a criminal, so just because you have encryption doesn’t mean you provide your personal information
IPsec and virtual private networks (VPNs)
- the authentication header
- the encapsulating security payload
- Originally created as part of IP version 6 protocols – when the adoption of IPv6 started taking longer than anticipitaed – we use it to build encrypted VPN tunnels
- Original TCP/ICP protocols did not provide any security – they were designed to function well. A lot of security software adds security at the OSI protocol stack’s application layer (S/MIME and PGP) – this can be good, but doing security at the application layer and keeping it transparent from the user is difficult
- The beauty of iPsec is that implements security at OSI Layer 3 – the network layer. This is where the OSI protocol stack that we find the internet protocol, which is where the name IPSec – security implemented at the IP layer.
- Means IP is transparent (we don’t think about the IP we’re connecting to when on the browser) this means that IPSec is also transparent to the user. So if you are sending your traffic over a VPN tunnel you don’t need to tell the software to encrypt this
- Historically, organizations wanting to communication between branch offices would purchase lease lines – where a telcom provider gives a guaranteed amount of bandwith from point A to point B – but this does not provide encryption of any kind, so you should still use a VPN on a leaseline.
- IPSec protects the IP packets by authenticating their origin, preventing replay attacks, ensuring their integrity and encrypting them. It consists of two main protocols:
o The Authentication Header, or AH, provides proof that a packet came from the computer indicated by the packet’s source address (authentication of origin). It verifies data integrity, which ensures that the data in the packet has not been altered during the transmission. AH also provides protection against replay attacks, meaning that an attacker cannot capture the packets and then resend them on the network at a later time. When combined, all these features provide for a much greater level of protection than ordinary IP traffic. The only thing the AH does not provide is data confidentiality; it does not encrypt the traffic. Because of this, seeing AH is somewhat rare today
o The Encapsulating Security Payload, or ESP, provides all of the same advantages of Authentication header in that it ensures authentication of origin, replay attack protection, and message integrity. In addition, ESP encrypts traffic. In the significant majority of cases where an organization is going to the trouble of implementing IPSec, they are doing so in order to ensure data encryption between endpoints. Therefore, most of the time when you find IPSec, you will see it using the ESP protocol.
VPN ESP modes:
- transport mode
- tunnel mode
- how do we route the packet
- rules to determine if we should use transport or tunnel mode
- The first mode to look at is Transport Mode which only encrypts and authenticates the transport header (where port numbers reside) and the data portions of the packet. This is used when you establish a “host-to-host” VPN. In other words, when both endpoints of encryption are also the endpoints of communication – one computer talking directly to another computer. This is not a very common scenario for VPN, so therefore, we won’t diagram here
- The second mode is Tunnel Mode and is very common, so we will focus on it. With tunnel mode, the original IP header, the transport header, and the data are all encrypted and authenticated. This makes for a very high degree of security, since an adversary cannot see the original IP addresses, they cannot see the original port numbers, or if it was TCP or UDP traffic (the combination of port number and TCP/UDP indicates the service being used), and they cannot see the data. There really is not much an adversary can tell about the communication at all beyond the fact that two parties are communicating.
- Of course, as soon as you see that the original IP header is encrypted, the question becomes, “how do you route the packet”? For now, the short answer is that there is a new IP header added at the head of the packet and the other information is encrypted
- When determining if you should use Transport Mode or Tunnel Mode, there is a simple rule to keep in mind.
o If either endpoint of communication is a gateway, then use Tunnel Mode
o In this context, a “gateway” is a router, firewall, or similar device that traffic must pass through to enter or leave a network.
o If both endpoints are computers, use Transport mode.
o To put that another way. Always use Tunnel Mode if your traffic travels via a network after the encryption is removed or if the traffic travels via a network before the encryption is added. By contrast, if BOTH the original source and destination of the traffic are also the computers doing the encryption, use Transport Mode.
VPN scenario #1: site-to-site tunnel mode
- picture on page 86
- The first scenario for VPN we will look at is Site-to-Site. You may also hear it referred to as “gatewayto-gateway”. In this scenario, we have one company with two branch offices. One office is in Dallas, Texas in the United States, the other is in London, United Kingdom. In a straight line, those two cities are about 4,750 miles (7,644 kilometer) apart.
- The network in Dallas is using the 10.1.1.0 address space. It’s firewall facing the Internet has a public address of 7.7.7.1. The network in London is using the 10.1.3.0 address space. It has an Internet firewall with a public address of 8.8.8.1. There is an encrypted ESP Tunnel Mode VPN between the public interfaces of the two firewalls. For all practical intent and purpose, both the 10.1.1.0 and 10.1.3.0 are now two subnets of one private network the intermediate gateway is just that far apart - We are creating a Virtually Private Network
- Here, a computer in Dallas with an IP address of 10.1.1.2 sends traffic to the computer 10.1.3.2 in London. When the packet leaves the 10.1.1.2 computer in route to the Dallas firewall, it has a source IP address of 10.1.1.2 and a destination address of 10.1.3.2 (the London computer). When the packet arrives at the firewall acting as the VPN endpoint, ESP encryption is added to the packet – meaning the original IP header, the transport header and the data are all encrypted.
- Of course, the ESP header and trailer are also added. When the new IP header is placed on the packet, it will now have a source IP address of the Dallas public IP 7.7.7.1 and a destination address of the London public IP 8.8.8.1. The packet routes across the Internet based on that addressing and arrives at the firewall in London. The London firewall removes the new IP header as well as the ESP header and trailer. The packet is decrypted and now has it’s original IP header. So the addressing once again is a source of 10.1.1.2 and a destination of 10.1.3.2. When the 10.1.3.2 computer responds, the destination IP in the unencrypted header will be 10.1.1.2 and the process repeats in the opposite direction.
- You need to realize, this is also true of your own security mechanisms. Whether the function be a firewall, an Intrusion Detection System (IDS), Intrusion Prevention System (IPS), Gateway Anti-Virus (GWAV) or anything else – If you put that function inside the tunnel, the security function is blinded. It cannot perform any analysis on the traffic. So all security mechanisms must be outside of the VPN tunnel in all cases!
VPN scenario #2 client-to-site tunnel mode
- a split tunnel
- a non split tunnel
- a split tunnel becomes a malware funnel
- Our second scenario is very common also. In fact, with more and more people working from home, this scenario is even more commonplace than it was just a few years ago. Here we see a traveling laptop connecting back to the company network
- The company network is using the 10.1.3.0 address space. Within that space, the administrators have set aside a pool of internal IP addresses for use by VPN clients. We will designate that range as 10.1.3.50 to 10.1.3.75. As you can see, the company’s firewall has a public IP address of 8.8.8.1
- In the hotel, which has a public IP address of 7.7.7.1, we find the traveling laptop. Before that laptop left on this trip, the admins installed VPN software on the computer. Part of the install process creates a virtual Network Interface Card (NIC). The admins used the VPN software to assign that virtual NIC an address of 10.1.3.55 (note, this is within the range of VPN addresses set aside).
- When the laptop sends traffic to the internal computer at 10.1.3.2, a packet is created inside the laptop with a source IP of 10.1.3.55 and a destination of 10.1.3.2. Before the packet ever leaves the laptop, the ESP Tunnel Mode encryption is added, encrypting the original IP header, transport header, and the data. ESP header and trailer are also added. The new IP header will have the address of the hotel, 7.7.7.1 as the source and the public address of the firewall, 8.8.8.1, as the destination. That packet routes from the hotel to the company’s firewall based on this addressing. The firewall’s VPN endpoint function will decrypt the packet and send it on with a source IP address of 10.1.3.55 and a destination of 10.1.3.2. When the 10.1.3.2 computer sends a response, it will have a source of 10.1.3.2 and a destination IP address of 10.1.3.55. Any traffic destined to one of the VPN pool addresses is routed through the VPN tunnel
- There are two ways of setting this kind of VPN up :
o Split tunnel : if laptop goes to internet like google, it goes directly there
o Non-split tunnel : once you establish the tunnel, 100% of the traffic passes through the tunnel, and if you want to go to the internet it passes through the corporate security
o A split tunnel becomes a malware funnel – malware comes on the internet it gets encrypted and it goes right through the VPN tunnel on my network – it’s more secure to set it up as non-split tunnel
VPN scenarion #3: public VPN providers
- picture on page 87
- Another type of VPN is sometimes referred to as Public VPN. With this type of VPN, you utilize a service and connect to one of their servers. You establish an encrypted tunnel from your device to the VPN server. At that point, your traffic is decrypted and sent out to the internet.
- Above, you see a laptop in Los Angeles, California with a VPN tunnel to Dallas, Texas. All traffic from the laptop to the server in Dallas is encrypted. Traffic from the Dallas server to the internet is unencrypted. Note: If you are using one of the encrypting protocols discussed in this module, such as HTTPS, that encryption would remain on the data once it passes the Dallas server and on out to the internet.
- In this scenario, all traffic from the laptop will be seen on the internet as coming from the Dallas server. In fact, if you have the setup depicted in the diagram and go into Google and ask it to show “restaurants near me”, it will show you eating establishments in the Dallas, Texas area even though you are physically in Los Angeles, California.