的層次不同提供的安全性也不同，例如，在網(wǎng)絡層提供虛擬私用網(wǎng)絡，在傳輸層提供安全套接服務。下面將分別介紹TCP/IP不同層次的安全性和提高各層安全性的方法。
一、Internet層的安全性
對Internet層的安全協(xié)議進行標準化的想法早就有了。在過去十年里，已經(jīng)提出了一些。例如，“安全協(xié)議3號(SP3)”就是美國國家安全局以及標準技術協(xié)會作為“安全數(shù)據(jù)網(wǎng)絡系統(tǒng)(SDNS)”的一部分而制定的?！熬W(wǎng)絡層安全協(xié)議(NLSP)”是由國際標準化組織為“無連接網(wǎng)絡協(xié)議(CLNP)”制定的安全協(xié)議標準?！凹苫疦LSP(I-NLSP)”是美國國家科技研究所提出的包括IP和CLNP在內(nèi)的統(tǒng)一安全機制。SwIPe是另一個Intenet層的安全協(xié)議，由Ioannidis和Blaze提出并實現(xiàn)原型。所有這些提案的共同點多于不同點。事實上，他們用的都是IP封裝技術。其本質(zhì)是，純文本的包被加密，在外層的IP報頭里，用來對加密的包進行Internet上的路由選擇。到達另一端時，外層的IP報頭被拆開，報文被解密，然后送到收報地點。
Internet工程特遣組(IETF)已經(jīng)特許Internet協(xié)議安全協(xié)議(IPSEC)工作組對IP安全協(xié)議(IPSP)和對應的Internet密鑰管理協(xié)議(IKMP)進行標準化工作。IPSP的主要目的是使需要安全措施的用戶能夠使用相應的加密安全體制。該體制不僅能在目前通行的IP(IPv4)下工作，也能在IP的新版本(IPng或)下工作。該體制應該是與算法無關的，即使加密算法替換了，也不對其他部分的實現(xiàn)產(chǎn)生影響。此外，該體制必須能實行多種安全政策，但要避免給不使用該體制的人造成不利影響。按照這些要求，IPSEC工作組制訂了一個規(guī)范：認證頭(Authentication Header，AH)和封裝安全有效負荷(Encapsulating Security Payload，ESP)。簡言之，AH提供IP包的真實性和完整性，ESP提供機要內(nèi)容。
IP AH指一段消息認證代碼(Message Authentication Code，)，在發(fā)送IP包之前，它已經(jīng)被事先計算好。發(fā)送方用一個加密密鑰算出AH，接收方用同一或另一密鑰對之進行驗證。如果收發(fā)雙方使用的是單鑰體制，那它們就使用同一密鑰;如果收發(fā)雙方使用的是公鑰體制，那它們就使用不同的密鑰。在后一種情形，AH體制能額外地提供不可否認的服務。事實上，有些在傳輸中可變的域，如IPv4中的time-to-live域或IPv6中的hop limit域，都是在AH的計算中必須忽略不計的。RFC 1828首次規(guī)定了加封狀態(tài)下AH的計算和驗證中要采用帶密鑰的MD5算法。而與此同時，MD5和加封狀態(tài)都被批評為加密強度太弱，并有替換的方案提出。
IP ESP的基本想法是整個IP包進行封裝，或者只對ESP內(nèi)上層協(xié)議的數(shù)據(jù)(運輸狀態(tài))進行封裝，并對ESP的絕大部分數(shù)據(jù)進行加密。在管道狀態(tài)下，為當前已加密的ESP附加了一個新的IP頭(純文本)，它可以用來對IP包在Internet上作路由選擇。接收方把這個IP頭取掉，再對ESP進行解密，處理并取掉ESP頭，再對原來的IP包或更高層協(xié)議的數(shù)據(jù)就象普通的IP包那樣進行處理。RFC 1827中對ESP的格式作了規(guī)定，RFC 1829中規(guī)定了在密碼塊鏈接(CBC)狀態(tài)下ESP加密和解密要使用數(shù)據(jù)加密標準(DES)。雖然其他算法和狀態(tài)也是可以使用的，但一些國家對此類產(chǎn)品的進出口控制也是不能不考慮的因素。有些國家甚至連私用加密都要限制。
AH與ESP體制可以合用，也可以分用。不管怎么用，都逃不脫傳輸分析的攻擊。人們不太清楚在Internet層上，是否真有經(jīng)濟有效的對抗傳輸分析的手段，但是在Internet用戶里，真正把傳輸分析當回事兒的也是寥寥無幾。
1995年8月，Internet工程領導小組(IESG)批準了有關IPSP的RFC作為Internet標準系列的推薦標準。除RFC 1828和RFC 1829外，還有兩個實驗性的RFC文件，規(guī)定了在AH和ESP體制中，用安全散列算法(SHA)來代替MD5(RFC 1852)和用三元DES代替DES(RFC 1851)。
在最簡單的情況下，IPSP用手工來配置密鑰。然而，當IPSP大規(guī)模發(fā)展的時候，就需要在Internet上建立標準化的密鑰管理協(xié)議。這個密鑰管理協(xié)議按照IPSP安全條例的要求，指定管理密鑰的方法。
因此，IPSEC工作組也負責進行Internet密鑰管理協(xié)議(IKMP)，其他若干協(xié)議的標準化工作也已經(jīng)提上日程。其中最重要的有：
IBM 提出的“標準密鑰管理協(xié)議(MKMP)”
SUN 提出的“Internet協(xié)議的簡單密鑰管理(SKIP)”
Phil Karn 提出的“Photuris密鑰管理協(xié)議”
Hugo Krawczik 提出的“安全密鑰制(SKEME)”
NSA 提出的“Internet安全條例及密鑰管理協(xié)議”
Hilarie Orman 提出的“OAKLEY密鑰決定協(xié)議”
在這里需要再次強調(diào)指出，這些協(xié)議草案的相似點多于不同點。除MKMP外，它們都要求一個既存的、完全可操作的公鑰基礎設施(PKI)。MKMP沒有這個要求，因為它假定雙方已經(jīng)共同知道一個主密鑰(Master Key)，可能是事先手工發(fā)布的。SKIP要求Diffie-Hellman證書，其他協(xié)議則要求RSA證書。
二、傳輸層的安全性
在Internet應用編程序中，通常使用廣義的進程間通信(IPC)機制來與不同層次的安全協(xié)議打交道。比較流行的兩個IPC編程界面是BSD Sockets和傳輸層界面(TLI)，在Unix系統(tǒng)V命令里可以找到。
在Internet中提供的首先一個想法便是強化它的IPC界面，如BSD Sockets等，具體做法包括雙端實體的認證，數(shù)據(jù)加密密鑰的交換等。Netscape通信公司遵循了這個思路，制定了建立在可靠的傳輸服務(如TCP/IP所提供)基礎上的安全套接層協(xié)議()。SSL版本3(SSL v3)于1995年12月制定。它主要包含以下兩個協(xié)議：
SSL記錄協(xié)議 它涉及應用程序提供的信息的分段、壓縮、數(shù)據(jù)認證和加密。SSL v3提供對數(shù)據(jù)認證用的MD5和SHA以及數(shù)據(jù)加密用的R4和DES等的支持，用來對數(shù)據(jù)進行認證和加密的密鑰可以通過SSL的握手協(xié)議來協(xié)商。
SSL握手協(xié)議 用來交換版本號、加密算法、(相互)身份認證并交換密鑰。SSL v3 提供對Deffie-Hellman密鑰交換算法、基于RSA的密鑰交換機制和另一種實現(xiàn)在 Fortezza chip上的密鑰交換機制的支持。
Netscape通信公司已經(jīng)向公眾推出了SSL的參考實現(xiàn)(稱為SSLref)。另一免費的SSL實現(xiàn)叫做SSLeay。SSLref和SSLeay均可給任何TCP/IP應用提供SSL功能。Internet號碼分配當局(IANA)已經(jīng)為具備SSL功能的應用分配了固定端口號，例如，帶SSL的 HTTP(https)被分配的端口號為443，帶SSL的SMTP(ssmtp)被分配的端口號為465，帶SSL的NNTP(snntp)被分配的端口號為563。
推出了SSL2的改進版本稱為PCT(私人通信技術)。至少從它使用的記錄格式來看，SSL和PCT是十分相似的。它們的主要差別是它們在版本號字段的最顯著位(The Most Significant Bit)上的取值有所不同: SSL該位取0，PCT該位取1。這樣區(qū)分之后，就可以對這兩個協(xié)議都給以支持。
1996年4月，IETF授權(quán)一個傳輸層安全(TLS)工作組著手制定一個傳輸層安全協(xié)議(TLSP)，以便作為標準提案向IESG正式提交。TLSP將會在許多地方酷似SSL。
前面已介紹Internet層安全機制的主要優(yōu)點是它的透明性，即安全服務的提供不要求應用層做任何改變。這對傳輸層來說是做不到的。原則上，任何TCP/IP應用，只要應用傳輸層安全協(xié)議，比如說SSL或PCT，就必定要進行若干修改以增加相應的功能，并使用(稍微)不同的IPC界面。于是，傳輸層安全機制的主要缺點就是要對傳輸層IPC界面和應用程序兩端都進行修改?？墒?，比起Internet層和應用層的安全機制來，這里的修改還是相當小的。另一個缺點是，基于UDP的通信很難在傳輸層建立起安全機制來。同網(wǎng)絡層安全機制相比，傳輸層安全機制的主要優(yōu)點是它提供基于進程對進程的(而不是主機對主機的)安全服務。這一成就如果再加上應用級的安全服務，就可以再向前跨越一大步了。
三、應用層的安全性
必須牢記(且須仔細品味): 網(wǎng)絡層(傳輸層)的安全協(xié)議允許為主機(進程)之間的數(shù)據(jù)通道增加安全屬性。本質(zhì)上，這意味著真正的(或許再加上機密的)數(shù)據(jù)通道還是建立在主機(或進程)之間，但卻不可能區(qū)分在同一通道上傳輸?shù)囊粋€具體文件的安全性要求。比如說，如果一個主機與另一個主機之間建立起一條安全的IP通道，那么所有在這條通道上傳輸?shù)腎P包就都要自動地被加密。同樣，如果一個進程和另一個進程之間通過傳輸層安全協(xié)議建立起了一條安全的數(shù)據(jù)通道，那么兩個進程間傳輸?shù)乃邢⒕投家詣拥乇患用堋?/P>
如果確實想要區(qū)分一個具體文件的不同的安全性要求，那就必須借助于應用層的安全性。提供應用層的安全服務實際上是最靈活的處理單個文件安全性的手段。例如一個電子郵件系統(tǒng)可能需要對要發(fā)出的信件的個別段落實施數(shù)據(jù)簽名。較低層的協(xié)議提供的安全功能一般不會知道任何要發(fā)出的信件的段落結(jié)構(gòu)，從而不可能知道該對哪一部分進行簽名。只有應用層是唯一能夠提供這種安全服務的層次。
一般來說，在應用層提供安全服務有幾種可能的做法，第一個想到的做法大概就是對每個應用(及應用協(xié)議)分別進行修改。一些重要的TCP/IP應用已經(jīng)這樣做了。在RFC 1421至1424中，IETF規(guī)定了私用強化郵件(PEM)來為基于SMTP的電子郵件系統(tǒng)提供安全服務。由于種種理由，Internet業(yè)界采納PEM的步子還是太慢，一個主要的原因是PEM依賴于一個既存的、完全可操作的PKI(公鑰基礎結(jié)構(gòu))。PEM PKI是按層次組織的，由下述三個層次構(gòu)成:
頂層為Internet安全政策登記機構(gòu)(IPRA)
次層為安全政策證書頒發(fā)機構(gòu)(PCA)
底層為證書頒發(fā)機構(gòu)(CA)
建立一個符合PEM規(guī)范的PKI也是一個政治性的過程，因為它需要多方在一個共同點上達成信任。不幸的是，歷史表明，政治性的過程總是需要時間的，作為一個中間步驟，Phil Zimmermann開發(fā)了一個軟件包，叫做PGP(pretty Good Privacy)。PGP符合PEM的絕大多數(shù)規(guī)范，但不必要求PKI的存在。