TLS

安全傳輸層協議（TLS）用於在兩個通信應用程序之間提供保密性和數據完整性。該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。較低的層為 TLS 記錄協議，位於某個可靠的傳輸協議（例如 TCP）上面，與具體的應用無關，所以，一般把TLS協議歸為傳輸層安全協議。

安全網路編程

早期的研究工作，為方便改造原有網路應用程序，在1993年已經有了相似的Berkeley套接字安全傳輸層API方法。

SSL 1.0、2.0和3.0

SSL（Secure Sockets Layer）是網景公司（Netscape）設計的主要用於Web的安全傳輸協議，這種協議在Web上獲得了廣泛的應用。

基礎演演算法由作為網景公司的首席科學家塔希爾·蓋莫爾（Taher Elgamal）編寫，所以他被人稱為“SSL之父”。

2014年10月，Google發布在SSL 3.0中發現設計缺陷，建議禁用此一協議。攻擊者可以向TLS發送虛假錯誤提示，然後將安全連接強行降級到過時且不安全的SSL 3.0，然後就可以利用其中的設計漏洞竊取敏感信息。Google在自己公司相關產品中陸續禁止回溯兼容，強制使用TLS協議。Mozilla也在11月25日發布的Firefox34中徹底禁用了SSL 3.0。微軟同樣發出了安全通告。

● 1.0版本從未公開過，因為存在嚴重的安全漏洞。

● 2.0版本在1995年2月發布，但因為存在數個嚴重的安全漏洞而被3.0版本替代。

● 3.0版本在1996年發布，是由網景工程師Paul Kocher、Phil Karlton和Alan Freier完全重新設計的。較新版本的SSL/TLS基於SSL 3.0。SSL 3.0作為歷史文獻IETF通過RFC 6101發表。

TLS 1.0

IETF將SSL標準化，即RFC 2246，並將其稱為TLS（Transport Layer Security）。從技術上講，TLS 1.0與SSL 3.0的差異非常微小。但正如RFC所述"the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0"（本協議和SSL 3.0之間的差異並不是顯著，卻足以排除TLS 1.0和SSL 3.0之間的互操作性）。TLS 1.0包括可以降級到SSL 3.0的實現，這削弱了連接的安全性。

TLS 1.1

TLS 1.1在RFC 4346中定義，於2006年4月發表，它是TLS 1.0的更新。在此版本中的差異包括：

● 添加對CBC攻擊的保護：

● ● 隱式IV被替換成一個顯式的IV。

● ● 更改分組密碼模式中的填充錯誤。

● 支持IANA登記的參數。

TLS 1.2

TLS 1.2在RFC 5246中定義，於2008年8月發表。它基於更早的TLS 1.1規範。主要區別包括：

● 可使用密碼組合選項指定偽隨機函數使用SHA-256替換MD5-SHA-1組合。

● 可使用密碼組合選項指定在完成消息的哈希認證中使用SHA-256替換MD5-SHA-1演演算法，但完成消息中哈希值的長度仍然被截斷為96位。

● 在握手期間MD5-SHA-1組合的數字簽名被替換為使用單一Hash方法，默認為SHA-1。

● 增強伺服器和客戶端指定Hash和簽名演演算法的能力。

● 擴大經過身份驗證的加密密碼，主要用於GCM和CCM模式的AES加密的支持。

● 添加TLS擴展定義和AES密碼組合。所有TLS版本在2011年3月發布的RFC 6176中刪除了對SSL的兼容，這樣TLS會話將永遠無法協商使用的SSL 2.0以避免安全問題。

TLS 1.3

參見：來回通信延遲

TLS 1.3在RFC 8446中定義，於2018年8月發表。它基於更早的TLS 1.2規範，與TLS 1.2的主要區別包括：

● 將密鑰協商和認證演演算法從密碼包中分離出來。

● 移除脆弱和較少使用的命名橢圓曲線支持（參見橢圓曲線密碼學）。

● 移除MD5和SHA-224密碼散列函數的支持。

● 請求數字簽名，即便使用之前的配置。

● 集成HKDF和半短暫DH提議。

● 替換使用PSK和票據的恢復。

● 支持1-RTT握手並初步支持0-RTT。

● 通過在(EC)DH密鑰協議期間使用臨時密鑰來保證完善的前向安全性。

● 放棄許多不安全或過時特性的支持，包括數據壓縮、重新協商、非AEAD密碼本、靜態RSA和靜態DH密鑰交換、自定義DHE分組、點格式協商、更改密碼本規範的協議、UNIX時間的Hello消息，以及長度欄位AD輸入到AEAD密碼本。

● 禁止用於向後兼容性的SSL和RC4協商。

● 集成會話散列的使用。

● 棄用記錄層版本號和凍結數以改進向後兼容性。

● 將一些安全相關的演演算法細節從附錄移動到標準，並將ClientKeyShare降級到附錄。

● 添加帶有Poly1305消息驗證碼的ChaCha20流加密。

● 添加Ed25519和Ed448數字簽名演演算法。

● 添加x25519和x448密鑰交換協議。

● 將支持加密伺服器名稱指示（EncryptedServerNameIndication, ESNI）。

網路安全服務（NSS）是由Mozilla開發並由其網路瀏覽器Firefox使用的加密庫，自2017年2月起便默認啟用TLS 1.3。隨後TLS 1.3被添加到2017年3月發布的Firefox 52.0中，但它由於某些用戶的兼容性問題，默認情況下禁用。直到Firefox 60.0才正式默認啟用。

Google Chrome曾在2017年短時間將TLS 1.3設為默認，然而由於類似Blue Coat Systems等不兼容組件而被取消。

wolfSSL在2017年5月發布的3.11.1版本中啟用了TLS 1.3。作為第一款支持TLS 1.3部署，wolfSSL 3.11.1 支持 TLS 1.3 Draft 18（現已支持到Draft 28），同時官方也發布了一系列關於TLS 1.2和TLS 1.3性能差距的博客。

TLS協議包括兩個協議組―― TLS 記錄協議和 TLS 握手協議――每組具有很多不同格式的信息。

TLS 記錄協議是一種分層協議。每一層中的信息可能包含長度、描述和內容等欄位。記錄協議支持信息傳輸、將數據分段到可處理塊、壓縮數據、應用 MAC 、加密以及傳輸結果等。對接收到的數據進行解密、校驗、解壓縮、重組等，然後將它們傳送到高層客戶機。

TLS 連接狀態指的是TLS 記錄協議的操作環境。它規定了壓縮演演算法、加密演演算法和 MAC 演演算法。

TLS 記錄層從高層接收任意大小無空塊的連續數據。密鑰計算：記錄協議通過演演算法從握手協議提供的安全參數中產生密鑰、 IV 和 MAC 密鑰。TLS 握手協議由三個子協議組構成，允許對等雙方在記錄層的安全參數上達成一致、自我認證、例示協商安全參數、互相報告出錯條件。

TLS記錄協議位於TLS握手協議的下面，在可靠的傳輸協議(如TCP/IP)上面。TLS記錄協議的一條記錄包含長度欄位、描述欄位和內容欄位。TLS記錄協議處理數據的加密，即記錄協議得到要發送的消息之後，將數據分成易於處理的數據分組，進行數據壓縮處理(可選)，計算數據分組的消息認證碼MAC，加密數據然後發送數據；接收到的消息首先被解密，然後校驗MAC值，解壓縮，重組，最後傳遞給協議的高層客戶。記錄協議有四種類型的客戶：握手協議、警告協議、改變密碼格式協議和應用數據協議。通常使用一個對稱演演算法，演演算法的密鑰由握手協議提供的值生成。

TLS 記錄協議提供的連接安全性具有兩個基本特性：

私有――對稱加密用以數據加密（DES 、RC4 等）。對稱加密所產生的密鑰對每個連接都是唯一的，且此密鑰基於另一個協議（如握手協議）協商。記錄協議也可以不加密使用。

可靠――信息傳輸包括使用密鑰的 MAC 進行信息完整性檢查。安全哈希功能（ SHA、MD5 等）用於 MAC 計算。記錄協議在沒有 MAC 的情況下也能操作，但一般只能用於這種模式，即有另一個協議正在使用記錄協議傳輸協商安全參數。

TLS 記錄協議用於封裝各種高層協議。作為這種封裝協議之一的握手協議允許伺服器與客戶機在應用程序協議傳輸和接收其第一個數據位元組前彼此之間相互認證，協商加密演演算法和加密密鑰。

TLS握手協議處理對等用戶的認證，在這一層使用了公共密鑰和證書，並協商演演算法和加密實際數據傳輸的密鑰，該過程在TLS記錄協議之上進行。TLS握手協議是TLS協議中最複雜的部分，它定義了10種消息，客戶端和伺服器利用這10種消息相互認證，協商哈希函數和加密演演算法並相互提供產生加密密鑰的機密數據。TLS記錄協議會在加密演演算法中用到這些加密密鑰，從而提供數據保密性和一致性保護。

TLS 握手協議提供的連接安全具有三個基本屬性：

1.可以使用非對稱的，或公共密鑰的密碼術來認證對等方的身份。該認證是可選的，但至少需要一個結點方。

2.共享加密密鑰的協商是安全的。對偷竊者來說協商加密是難以獲得的。此外經過認證過的連接不能獲得加密，即使是進入連接中間的攻擊者也不能。

3.協商是可靠的。沒有經過通信方成員的檢測，任何攻擊者都不能修改通信協商。

TLS握手協議：

1.改變密碼規格協議

2.警惕協議

3.握手協議

TLS 的最大優勢就在於：TLS 是獨立於應用協議。高層協議可以透明地分佈在 TLS 協議上面。然而，TLS 標準並沒有規定應用程序如何在 TLS 上增加安全性；它把如何啟動 TLS 握手協議以及如何解釋交換的認證證書的決定權留給協議的設計者和實施者來判斷。

TLS包含三個基本階段：

1.對等協商支援的密鑰演演算法

2.基於私鑰加密交換公鑰、基於PKI證書的身份認證

3.基於公鑰加密的數據傳輸保密

TLS:Terrestrial Laser Scaner

地面三維激光掃描(TLS)是在地面利用激光掃描裝置自動、系統、快速(准實時)獲取對象表面的三維坐標的測量技術。它是一種高精度的測量手段。激光掃描與傳統的單點測量(如全站儀、 GPS測量)不同 ,可以獲取被掃對象表面成千上萬個點的三維坐標 ,但卻無法對某一指定點進行測量從而精確獲取其坐標。

TLS全稱為Thread Local Storage，是Windows為解決一個進程中多個線程同時訪問全局變數而提供的機制。TLS可以簡單地由操作系統代為完成整個互斥過程，也可以由用戶自己編寫控制信號量的函數。當進程中的線程訪問預先制定的內存空間時，操作系統會調用系統默認的或用戶自定義的信號量函數，保證數據的完整性與正確性。

Windows的可執行文件為PE格式，在PE格式中，專門為TLS數據開闢了一段空間，具體位置為

IMAGE_NT_HEADERS.OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_TLS]。

其中DataDirectory的元素具有如下結構：

typedef struct _IMAGE_DATA_DIRECTORY {

DWORD VirtualAddress;

DWORD Size;

} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

對於TLS的DataDirectory元素，VirtualAddress成員指向一個結構體，結構體中定義了訪問需要互斥的內存地址、TLS回調函數地址以及其他一些信息。

當用戶選擇使用自己編寫的信號量函數時，在應用程序初始化階段，系統將要調用一個由用戶編寫的初始化函數以完成信號量的初始化以及其他的一些初始化工作。此調用必須在程序真正開始執行到入口點之前就完成，以保證程序執行的正確性。

TLS回調函數具有如下的函數原型：

void NTAPI TlsCallBackFunction(PVOID Handle, DWORD Reason, PVOID Reserve);

東京插畫家協會，(Tokyo Illustrators Society) 簡稱TLS，成立於1998年10月，這裡不僅是日本插畫家結識交流的平台，也是展示插畫家藝術成就的舞台。截至2012年3月，東京插畫家協會共有218名會員。為了幫助插畫事業的發展，協會舉辦了諸如展覽、以培養年青一代為目的的公開招聘等活動。

行政人員：

協會的理事長：安西水丸。

副理事長：筒啟之、都築潤、南伸坊

代理主管：山崎杉夫

協會會員：

秋山育

秋山 孝

淺賀行雄

あずみ蟲

阿部隆夫

あべ弘士

網中いづる

新井苑子

新目 惠

安齋 肇

安西水丸

等

TLS（Transparent LAN Services）透明區域網服務：當用戶埠TLS使能時，針對用戶口來的tag報文，在原來的報文802.1q四個位元組前再加上相應的TLS vlan後上傳。該配置主要用於企業和企業間的VLAN透傳。

在T12P2版本之前只支持tls vlan，對一個ONU上所有的內層vlan打上一個外層tls vlan上傳。在上聯口上根據tls vlan的tag或untag屬性，決定tls vlan標籤的透傳還是剝離

主要應用場景是用戶接入的數據報文帶有vlan標籤，要求系統為其再添加一層vlan標籤，送入上層網路。比如用戶報文帶有vlan標籤100，要求系統為其添加VLAN 101的標籤。