Year ago, Netscape Communications created some of the basic products and protocols that have largely defined the Second (IPv4 based) Internet. These included the first commercially viable browser (Netscape Navigator), the first commercially viable Web Server (Netscape Web Server) and SSL (Secure Sockets Layer).
Originally SSL was a proprietary protocol owned and controlled by Netscape. It became so widely used that it was released to the IETF, who renamed it TLS for Transport Layer Security (which is curious because it exists within the Application Layer, or more specifically a shim between the Application Layer and the Transport Layer).
When you surf to a site over HTTPS that is HTTP over TLS. When you connect securely to an email server with SMTPS that is SMTP over TLS. While TLS was originally designed just for the web, it is now used with many protocols, including SMTP, IMAP, LDAP, IRP, SixID, etc. TLS itself runs over TCP (from the TCP/IP Transport Layer). There is a version that works over UDP, for connectionless traffic.
Sixscape Communications pays homage to Netscape Communications as being “the Netscape for the IPv6 Internet”. We are creating breakthrough products and protocols that may well define the IPv6 and 5G global networks.
The Splintered IPv4 Internet (Public vs Private Addresses)
Prior to the mid 1990s, the IPv4 Internet had a flat (monolithic) address space with only public, globally routable IP addresses. Any node in the world could connect directly to any other node, unless the path between them was blocked by a router or firewall.
About 1995, the IETF realized at the rate addresses were being allocated, by 2000 they would all be gone. So they created Network Address Translation and RFC 1918 “Addresses for Private Internets” as a temporary stopgap to extend the life of the IPv4 address space to roughly 2010. This is similar to a business telephone system Private Branch Exchange (PBX). A public IPv4 address is like a real telephone number, while a private IPv4 address is like an internal extension behind a PBX. This has allowed connecting some 20 billion nodes to the IPv4 Internet, but at the cost of creating millions of private internets, each of which is hiding behind one public IPv4 address. Unfortunately we are now at 2020 and only about 30% of the traffic on the global Internet is over IPv6.
If the address of your node begins with 10, or 172.16 to 172.31, or 192.168, you have a private address behind a NAT gateway. You can make outgoing connections through your NAT gateway to external nodes with a public address , but no external node (outside of your private internet) can connect to you. Once an outgoing connection is made, traffic can flow in both directions. But you can’t run a server in your private internet or do a real peer-to-peer connection to any node outside of your private internet. If you also have an IPv6 address, that is public and you can make outgoing connections to any other IPv6 node and accept incoming connections from any other IPv6 node. That is called Dual Stack. eventually most of us will be running only IPv6, and accessing external legacy (IPv4-only) nodes via NAT64/DNS64 gateways.
IPv4 Address Exhaustion
In 2011, IANA allocated the final unallocated blocks of IPv4 public addresses to the RIRs (APNIC, ARIN, RIPE, LACNIC and AfriNIC). There are no more block of IPv4 public addresses left and no way to create more. Over the next few years, the RIRs reached “end of normal allocation” of IPv4 public addresses. Now many ISPs are deploying Carrier Grade NAT (CGN) which has two layers of NAT – one at the ISP and another in the home or business. This is like a PBX behind another PBX.
Note: some ISPs still use the old term “static address” when they mean “public address”. This goes back to dial-up access days, when all addresses were public, but many ISPs would reuse the same address pool over and over again for a large number of dial-in users. When one person hung up, that address became available for another customer, which was called “dynamic IP address”. You could get a dedicated address just for you, at higher cost. Those were called “static IP addresses”. You can assign a static private IP address to an node, but that doesn’t make that address routable on the global Internet.
Public IPv4 addresses include all addresses that are not private addresses (RFC 1918), or assigned as multicast or experimental addresses, or any other special purpose, like 127/8, which is the loopback address (yes, all 16.7 million addresses in that block are loopback addresses – try using 127.1.2.3 – works the same as 127.0.0.1).
SSL (TLS) Was Designed for the Client/Server Model
SSL was designed for an Internet based on IPv4 with Network Address Translation (NAT). A node behind NAT (most nodes on the IPv4 Internet today) can only make an outgoing connection to an external node via a NAT gateway. A NAT gateway maps the node’s private address onto a public address, which can connect to a server with a public address. NAT forces us to use Client/Server architecture with a few (mostly static) centralized nodes that have public addresses and many decentralized clients that have private addresses.
SSL normally only needs one server cert, for the centralized shared server used by possibly millions of clients. That server cert identifies the server by Fully Qualified Domain Name (nodename with domain name, e.g. www.pkiedu.com). To get it you have to convince a CA that you have rights to use the domain name (CN=pkiedu.com) and ideally also the organization name (e.g. O=PKIEdu Inc.). You might include other fields such as Locality (city), State and Country. This cert enables SSL/TLS encryption and provides server to client authentication. If only a server cert is used (very common) then some other mechanism (e.g. username/password) must be used to authenticate the user (client) to the server.
With IPv4 + NAT, you can’t have real peer-to-peer connections, except within a single private internet. Skype looks like it is peer-to-peer, but it does this using NAT Traversal. This uses an external STUN server to accept connections on behalf of the private client. The client makes an outgoing connection to the STUN server and allows traffic from the accepted connections to come back down the outgoing connection to the STUN server. This is actually a big security risk, as the client bypasses your firewall. It’s like having an “inside man” on a bank robbery.
With PeerTLS, both nodes use a client cert, which identifies their users, not the nodes. There is only one link between them, so TLS can provide end-to-end encryption for any protocol, as well as mutual strong authentication. This is possible only when both ends have IPv6 addresses, or within an IPv4 private internet. PeerTLS does away with intermediate servers. Every node has both a client (that can initiate outgoing connections) and a server (that can accept incoming connections). This is called a User Agent. I had to create a new directory service (SixID) to allow any node to securely register (and update) their IPv6 address (and other identifying information, including their digital certificate, and allow others to securely retrieve that information. DNS is not adequate for end-to-end direct messaging.
Strong Client Authentication with a Client Cert
TLS (since SSL v3.0) also supports using a client certificate during the handshake to strongly authenticate the client (user) to the server (after the server to client authentication). If you use this, the server must be configured to support client authentication (options are “require cert” or “allow cert”). Each user requires a unique cert that identifies them. This is much more difficult to provide than a single server cert. Each user’s identity must be validated by the client cert issuer (which can be a public hierarchy CA like GlobalSign, or a private hierarchy CA run by an organization, e.g. using Microsoft Certificate Services or EJBCA).
For details on this, see Cryptographic Authentication.
TLS Secures One Client/Server Network Link
TLS provides only a few things:
- Server to Client Authentication
- Optional Client to Server Authentication
- Exchange of a Symmetric Session Key to support encryption between client and server
For Web, this is not a problem. All Web connections involve only one link (from web browser to web server). If I click on a link, the server doesn’t make an ongoing connection, my browser makes a new one-link connection to another server (which might also be secured with TLS or not).
For Email, there are a minimum of two links (if both parties have accounts on the same Email server), or more commonly three or more links:
- Alice client to Alice’s Mail Server (using SMTP or IMAP)
- Alice’s Mail Server to Bob’s Mail Server (using SMTP)
- Bob’s client to Bob’s Mail Server (using IMAP)
Each of these links must be secured independently with TLS, and even then the traffic is in plaintext on the server(s). This is not end-to-end encryption.
Each server authenticates itself to the corresponding client (Alice’s Mail Server assumes the client role when it relays the message to Bob’s Mail Server). There is no original sender to final recipient authentication, let alone mutual authentication, even if Strong Client Authentication is used.
You can provide end-to-end encryption and sender to recipient authentication for Email with S/MIME, which is entirely based in the clients – servers are transparent to S/MIME. The encrypted and/or signed messages flow right through them – they aren’t even aware this is happening. S/MIME does involve issuing an S/MIME cert to every user and providing a shared address book that supports digital certificates.