TLS1.0 協議發布於1999年初。該協議可在Internet中提供給通信雙方一條私有信道，即對通信消息進行加密。該協議主要描述了通信密鑰協商的方法與通信格式的定義。分別由TLS Handshake Protocol 和 TLS Record Protocol兩個子協議進行描述。雖然TLS1.0已經退出了歷史舞台，但其最初的TLS設計核心過程並無太大變化。因此有助於理解TLS協議的執行過程。
TCP協議為TLS協議提供傳輸層服務， TLS Record Protocol在TCP協議層之上，向上提供兩種服務：
- 通信雙方的連接是私有的。通信過程時的數據加密方式采用對稱加密。對於每一條連接來說，都有其唯一的對稱密鑰。用於加密數據的對稱密鑰是由TLS Handshake Protocol協商得到的。在特殊情況下，TLS Record Protocol層的數據也可以不被加密。
- 通信雙方的連接是可靠的。消息在傳遞過程中需要包含消息校驗碼（MAC），消息校驗碼采用Hash函數對消息進行摘要得出。
TLS Handshake Protocol提供密鑰協商服務，該協議允許服務器與客戶端相互驗證對方身份、協商對稱加密算法及對稱密鑰：
- 使用公鑰加密體系對通信雙方進行身份認證。身份認證過程的參與者是可選的，但至少對其中一方進行驗證。
- 協商過程中的共享秘密是安全的。協商秘密的過程中，攻擊者難以通過截獲協商過程中的數據，來推導出通信雙方的共享秘密。
- 協商過程是可信的。攻擊者不可能修改協商過程中的數據
在TLS中，多數操作是需要消息MAC（消息認證碼）來驗證消息的真實性。傳統的消息認證碼，僅僅是對消息進行Hash得以獲取，因此易於攻擊者對其進行偽造。若通過對MAC生成過程中添加私有秘密的方法來生成消息認證碼，偽造過程將十分困難（因為必須要猜出私有秘密）。使用HMAC作為消息認證碼。HMAC的生成可以使用多種不同的Hash算法。
TLS Record Protocol
TLS記錄協議將上層來的數據切成若干的數據塊，可選擇性地對這些數據塊進行壓縮，計算其MAC值，以及對數據進行加密，最后將經過加工后的數據放置在TCP協議中傳遞出去。同樣地，該協議會將接受到的TCP數據，進行解密、驗證、解壓、重組等過程，最后向上交付數據。
TLS Record Protocol包含四個子協議，分別為:
- handshake protocol
- alert protocol
- change cipher spec protocol
- application data protocol
TLS Handshake Protocol
TLS握手協議包含三個字協議：
- 選擇使用Record Protocol協商獲得的加密參數
- 驗證通信雙方身份
- 提供協商使用的加密參數，並報告錯誤
加密所需的參數由該協議協商得出，在客戶端與服務器開始通信時，雙方需要一致協議版本、選擇加密算法，對通信雙方進行身份認證，並使用公鑰加密體系生成共享秘密。該協議的規程如下：
- Client首先發送一個ClientHello給Server，該報文中包含版本號、隨機數（Client Random）及支持的加密算法
- Server返回包括 ServerHello、Certificate（可選，服務器的認證證書）、ServerKeyExchange （可選）、CertificateRequest（可選）、ServerHelloDone 作為應答，返回給Client，該報文中包含隨機數（Server Random）
- Client根據Server的ServerHello應答做出相應 Certificate（可選，當服務器應答中包含CertificateRequest時，需要提供客戶端認證證書）、ClientKeyExchange、CertificateVerify（可選）、[ChangeCipherSpec]、Finish。當且僅當Client掌握公鑰時，該報文中包含客戶端產生的新的隨機數，該隨機數使用服務器Certificate中的公鑰進行加密（Premaster secret）
- 服務器返回 [ChangeCipherSpec] Finished，當且僅當Server掌握公鑰時，該報文中包含服務器產生的新的隨機數，該隨機數使用客戶端的Certificate中的公鑰進行加密（Premaster secret）。該過程，對方將使用三個隨機數產生session key（會話密鑰）
值得注意的是，整個握手階段是不加密的，因此攻擊者可獲取到雙方選擇的加密方法以及前兩個隨機數，整個會話的安全性依賴於第三個隨機數。至此完成TLS握手過程。