Computer Science
SSL encryption
SSL encryption, or Secure Sockets Layer encryption, is a security protocol used to establish an encrypted link between a web server and a browser. It ensures that data transmitted between the two remains private and secure. SSL encryption is commonly used to protect sensitive information such as login credentials, credit card details, and personal data during online transactions.
Written by Perlego with AI-assistance
Related key terms
1 of 5
11 Key excerpts on "SSL encryption"
eBook - PDF- Syngress(Author)
- 2000(Publication Date)
- Syngress(Publisher)
We cover both the theory of each technology and its implementation in Windows 2000. Security is a rapidly changing field. You can think of security technologies as antibiotics for your network. The problem with antibiotics is that the germs develop a resistance to them, and new antibiotics are required to treat the same bacteria. Intruders are the disease of your network. Present technologies demand frequent upgrades, and new technologies need implementation as they are developed. In this vein, you should be sure to check the Microsoft Secure TCP/IP Connections • Chapter 6 299 Security Web site on a regular basis for warnings and patches to the security components of the operating system. SSL The Secure Sockets Layer (SSL) describes an encr5^tion technology widely used on the Internet to secure Web pages and Web sites. In this section, we will take a high-level look at SSL and discuss meth-ods used by SSL to encrypt information to keep it secure. Overview of SSL The Secure Sockets Layer is classified as a Transport Layer security protocol. SSL is a Transport Layer protocol because it results in securing the Transport Layer as well as information generated at the Application Layer. SSL provides secure communications for applications supporting its use. It provides mechanisms supporting the basic elements of secure communications. These are: • Authentication • Integrity • Confidentiality Authentication ensures that the information you receive is indeed from the individual you think you are receiving it from. Integrity guarantees the message you receive is the same message that was sent. Confidentiality protects data from inspection by unintended recipients. SSL lies between the Application and the Transport Layer. It pro-tects information passed by Application protocols such as FTP, HTTP, and NNTP. An application must be explicitly designed to sup-port SSL's security features.
- Syngress(Author)
- 2000(Publication Date)
- Syngress(Publisher)
In this section, we take a mile-high view of SSL and discuss the methods used by SSL to encrypt information to keep it secure. Overview of SSL SSL is classified as a Transport layer security protocol, since it secures not only the information generated at the Application layer, but at the Transport layer as well. It is considered a secure protocol by providing the mechanisms for supporting the basic elements of secure communications, namely: SSL lies between the Application and the Transport layers (review Chapter 11, “Inside Windows 2000 TCP/IP,” for more details on the TCP/IP and OSI models). It protects information passed by application protocols such as FTP, HTTP, and NNTP. An application must be explicitly designed to support SSL’s security features. Unlike Layer 3 protocols (such as IPSec covered later in this chapter), it is not transparent to Application layer processes. SSL uses several protocols to provide security and reliable communica-tions between client and server SSL-enabled applications. Specifically, the handshake protocol negotiates levels and types of encryption, and sets up the secure session. These include SSL protocol version (2.0 or 3.0), authen-tication algorithms, encryption algorithms, and the method used to gen-erate a shared secret or session key. SSL uses a record protocol to exchange the actual data. A shared ses-sion key encrypts data passing between SSL applications. The data is decrypted on the receiving end by the same shared session key. Data integrity and authentication mechanisms are employed to ensure that accu-rate data is sent to, and received by, legitimate parties to the conversation. SSL uses an alert protocol to convey information about error conditions during the conversation. It is also used by SSL hosts to terminate a session. How a Secure SSL Channel Is Established To understand how a secure channel is formed, let’s examine how an SSL client establishes a session with an SSL Web server: 1.
eBook - PDFCodes
The Guide to Secrecy From Ancient to Modern Times
- Richard A. Mollin(Author)
- 2005(Publication Date)
- Chapman and Hall/CRC(Publisher)
The security model of SSL is that it encrypts the channel by enciphering the bits that go through that channel. As mentioned earlier, SSL began with Netscape who originated it and in 1996, they handed over the spec-ifications of SSL to IETF who worked to standardize the SSL version 3 model, which had been released in 1995. In 1999, the TLS working group released TLS version 1, which has now become the IETF standards-track variant of the SSL version 3 protocol (see [68]). The cryptographic power of SSL/TLS is that it operates at the transport level so HTTP runs on top of SSL, called HTTPS. To understand the layers of SSL, we must introduce the names of the two main subprotocols to be discussed in detail below: (1) the handshake protocol; which operates above the (2) record protocol. This is illustrated below. HTTP SSL Handshake Protocol SSL Record Protocol TCP IP Data Link Layer Physical Layer 5.7. Protocol Layers 221 We begin by describing the lower level of SSL. ◆ SSL Record Protocol This protocol defines the format used to transmit data, and is used by the handshake protocol to exchange messages between client and server. First the message to be transmitted is fragmented , which means it breaks the message down into manageable blocks. Then it compresses the data (but this is an optional exercise in SSL). It then applies a MAC (see page 136), enciphers the data, adds a header, and transmits the cryptogram as a TCP unit. This is illustrated in Diagram 5.2. Diagram 5.2 SSL Record Protocol Actions Message Data Fragment Fragment · · · Fragment Fragment ✞ ✝ ☎ ✆ Compress Compressed Data Add MAC Encipher Add Header Cryptogram Transmit Upon receipt of the transmitted data, it is deciphered, authenticated, de-compressed, reassembled, and delivered to users at higher levels. 222 5. Cryptographic Protocols ▼ Analysis : The message data is typically fragmented into blocks of 2 14 bytes, after which data compression is optional.
No longer available |Learn more- (Author)
- 2014(Publication Date)
- White Word Publications(Publisher)
____________________ WORLD TECHNOLOGIES ____________________ Chapter-6 Transport Layer Security Transport Layer Security ( TLS ) and its predecessor, Secure Sockets Layer ( SSL ), are cryptographic protocols that provide communications security over the Internet. TLS and SSL encrypt the segments of network connections above the Transport Layer, using symmetric cryptography for privacy and a keyed message authentication code for message reliability. Several versions of the protocols are in widespread use in applications such as web browsing, electronic mail, Internet faxing, instant messaging and voice-over-IP (VoIP). TLS is an IETF standards track protocol, last updated in RFC 5246 and is based on the earlier SSL specifications developed by Netscape Corporation. Description The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering. A TLS client and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security. • The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and presents a list of supported CipherSuites (ciphers and hash functions). • From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision. • The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA) and the server's public encryption key. • The client may contact the server that issued the certificate (the trusted CA as above) and confirm that the certificate is valid before proceeding.
eBook - ePubPractical Embedded Security
Building Secure Resource-Constrained Systems
- Timothy Stapko(Author)
- 2011(Publication Date)
- Newnes(Publisher)
CHAPTER 4 The Secure Sockets LayerThe Secure Sockets Layer is so important to Internet security that we have devoted this entire chapter to it. SSL is the de facto standard for secure Internet transactions. It has achieved this status by being not only secure, but being highly generic and imminently practical as well. SSL exists in the network layer between TCP and your application, providing blanket security to all data transferred over the network. The API for an SSL implementation is typically very similar to the standard network sockets API (POSIX-style). For this reason, it is simple to transform any plain TCP/IP application into a secure Internet application with very little effort.In this chapter we will look at how to implement SSL for embedded platforms. The standard is very flexible in algorithm choice and features, so it is easy to pick and choose the features from a requirement list. Most PC-based implementations of SSL are monolithic—all features are compiled into every application. However, due to the specialized nature of embedded applications, we will look at a more modular approach, allowing the developer to enable only the features that are needed, leaving the rest out of the final binary.Aside from looking at structural procedures for making SSL work on embedded machines, we will also look at optimizations. Most of these will have been covered in previous chapters, since SSL uses common algorithms, but there are a few more tricks we can apply to make SSL work. We will look at hardware assistance as well, since SSL makes use of public-key cryptography, and some vendors have chosen to implement part or all of SSL in a hardware solution. We will also look at implementing SSL in hardware, as part of an FPGA, or as a stand-alone chip. Again, the advantage of hardware implementations is the ability to use larger keys and achieve the same or better performance. We will look at the tradeoffs between these hardware solutions, and a more flexible software implementation.
No longer available |Learn more- (Author)
- 2014(Publication Date)
- Academic Studio(Publisher)
________________________ WORLD TECHNOLOGIES ________________________ Chapter-9 Transport Layer Security Transport Layer Security ( TLS ) and its predecessor, Secure Sockets Layer ( SSL ), are cryptographic protocols that provide communications security over the Internet. TLS and SSL encrypt the segments of network connections above the Transport Layer, using symmetric cryptography for privacy and a keyed message authentication code for message reliability. Several versions of the protocols are in widespread use in applications such as web browsing, electronic mail, Internet faxing, instant messaging and voice-over-IP (VoIP). TLS is an IETF standards track protocol, last updated in RFC 5246 and is based on the earlier SSL specifications developed by Netscape Corporation. Description The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering. A TLS client and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security. • The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and presents a list of supported CipherSuites (ciphers and hash functions). • From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision. • The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA) and the server's public encryption key. • The client may contact the server that issued the certificate (the trusted CA as above) and confirm that the certificate is valid before proceeding. • In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server.
eBook - PDFIntroduction to Computer and Network Security
Navigating Shades of Gray
- Richard R. Brooks(Author)
- 2013(Publication Date)
- Chapman and Hall/CRC(Publisher)
The Secure Socket Layer (SSL) was created by Netscape Communications to provide web browsers with methods for secure communications. The first pub-lic SSL release was version 2.0, which in 1994 was bundled into the Netscape Navigator browser. SSL version 3 was the basis of the Transport Layer Secu-rity (TLS) protocol defined in RFC-2246. While TLS is not strictly compatible with SSL, it is as similar with SSL version 3 as SSL version 3 is with earlier versions of SSL [394] and may reasonably be considered as a new SSL ver-sion. In any case, TLS falls back to SSL when the other side does not support TLS [241]. Internet Protocol (IP) Transport Control Protocol (TCP) Internet Protocol (IP) Transport Control Protocol (TCP) Transport Layer Security (SSL/TLS) Hypertext Transport Protocol (HTTP) Hypertext Transport Protocol (HTTP) FIGURE 4.2 Normal web traffic (left) consists of HTTP packets being inserted into a TCP session, which provides reliable transport over the unreliable IP layer. SSL/TLS secured traffic (right) inserts an extra protocol layer to authenticate participants, encrypt, and decrypt traffic. In this chapter, we consider SSL/TLS use within a web browser (see Fig-ure 4.1). We will not consider security issues on the client machine, such as man-in-the-browser, cross site scripting (XSS), and cross site request forgery (XSRF) vulnerabilities. Neither will we discuss security issues due to pos-sible corruption of the web server. We assume both of these machines work correctly, and will therefore discuss solely how SSL/TLS secures network com-munications. We will concentrate on the numerous security issues that remain unresolved. SSL/TLS is bundled into web browsers to secure their communications with web servers. SSL/TLS is not solely used for web browser Hypertext 1 Much of the information presented in this chapter is based on a paper published at the 6th annual CSIIR Workshop held at Oak Ridge National Laboratory in April 2010 [91].
eBook - PDF- Ido Dubrawsky, Jeremy Faircloth(Authors)
- 2007(Publication Date)
- Syngress(Publisher)
SSL makes it possible for SSL-enabled clients and servers to authenticate themselves to each other and to encrypt and decrypt all data passed between them, as well as to detect tampering of data, after a secure encrypted connection has been established. www.syngress.com 278 Chapter 5 • Communication Security: Web Based Services SSL is made up of two protocols, the SSL record protocol and the SSL handshake protocol . SSL record protocol is used to define the format used to transmit data, while the SSL handshake protocol uses the record protocol to exchange messages between the SSL-enabled server and the client when they establish a connection. Together, these protocols facilitate the definition of the data format that is used in the transaction and to negotiate the level of encryption and authentication used. SSL supports a broad range of encryption algorithms, the most common of which include the RSA key exchange algorithms and the Fortezza algorithms.The Fortezza encryption suite is used more by U.S. government agencies. SSL 2.0 does not support the Fortezza algorithms. Its lack of backward compatibility may be another reason why it is less popular. The SSL handshake uses both public-key and symmetric-key encryption to set up the connection between a client and a server.The server authenticates itself to the client (and optionally the client authenticates itself to the server) using Public Key Cryptography Standards (PKCS).Then the client and the server together create symmetric keys, which they use for faster encryption, decryption, and tamper detec-tion of data within the secure connection.The steps are illustrated in Figure 5.8.
eBook - PDF- James Joshi(Author)
- 2008(Publication Date)
- Morgan Kaufmann(Publisher)
There are several issues of concern when sending your credit card information to a computer on the Web. First, you might worry that the information would be intercepted in transit and subsequently used to make unauthorized purchases. You might also worry about the details of a transaction being modified, for example, to change the purchase amount. And you would certainly like to know that the com-puter to which you are sending your credit card information is in fact one belong-ing to the vendor in question and not some other party. Thus, we immediately see a need for confidentiality, integrity, and authentication in Web transactions. The first widely used solution to this problem was SSL, originally developed by Netscape and subsequently the basis for the IETF’s TLS standard. The designers of SSL and TLS recognized that these problems were not specific to Web transactions (i.e., those using HTTP) and instead built a general-purpose protocol that sits between an application protocol such as HTTP and a transport protocol such as TCP. The reason for calling this “transport layer security” is that, from the application’s perspective, this protocol layer looks just like a normal transport protocol except for the fact that it is secure. That is, the sender can open connections and deliver bytes for transmission, and the secure transport layer will get them to the receiver with the necessary confidentiality, integrity, and authenti-cation. By running the secure transport layer on top of TCP, all of the normal fea-tures of TCP (reliability, flow control, congestion control, etc.) are also provided to the application. This arrangement of protocol layers is depicted in Figure 1.15. Application (e.g., HTTP) Secure transport layer TCP IP Subnet FIGURE 1.15 Secure transport layer inserted between application and TCP layers. 31 When HTTP is used in this way, it is known as HTTPS (Secure HTTP).
eBook - ePub- Mostafa Hashem Sherif(Author)
- 2017(Publication Date)
- CRC Press(Publisher)
Transport Layer Security and Secure Sockets LayerSecure Sockets Layer (SSL) and Transport Layer Security (TLS) are two widely used protocols to secure exchanges at the transport layer between a client and a server. SSL Version 1.0 was used internally within Netscape. Version 2.0 was released to the public in 1994 and integrated into the Netscape Navigator. Version 3.0 corrected deficiencies found in Version 2.0 and was the basis for RFC 2246 that defined TLS 1.0 in 1999 (Freier et al., 1996; Rescorla, 2001). TLS 1.0 was allowed for use to protect U.S. federal data; in contrast, SSL v3 was tolerated in limited, low-risk circumstances, such as to access vendor sites that did not support TLS (Chernick et al., 2005, p. 21, n. 20). TLS 1.0 was next adapted to wireless communication as Wireless TLS (WTLS). Two updates of TLS in 2006 and 2008, respectively, TLS 1.1 and 1.2, are defined in RFCs 4346 and 5246; these updates included a variety of countermeasures and workarounds to reported security threats. Finally, in 2011, RFC 6151 officially withdrew SSL Version 2.0. In parallel, the Datagram Transport Layer Security (DTLS) of RFC 4347 was defined to run on top of unreliable transport protocols; DTLS was later updated in RFC 6347. WTLS is discussed in Chapter 6 .This chapter focuses on the exchanges and during session and connection establishment for both SSL and TLS, explaining the main differences between the successive versions. Some (but not all) of the attacks against TLS/SSL are discussed. In fact, abundant information concerning possible attacks and how to defend against them is available. As usual, the primary references remain the standard documents mentioned in the text.5.1 Architecture of SSL/TLS
Figure 5.1 shows the location of SSL/TLS in the TCP/IP protocol stack. It is seen that they operate above the transport layer and below the application layer of the OSI (Open systems interconnection) reference model. The handshake for session and connection establishment is at the session layer. During that handshake, the various cryptographic parameters are established to be used in the presentation layer to support various application protocols, such as S-HTTP (Secure HyperText Transfer Protocol) of RFC 2660 (1999). Because SSL/TLS are readily incorporated in browsers, they have totally eclipsed the SET (Secure Electronic Transaction) protocol, which was specifically designed to secure bank card transactions. SET is presented in Chapter 7
Available until 8 Dec |Learn more- Mostafa Hashem Sherif(Author)
- 2003(Publication Date)
- CRC Press(Publisher)
The site http://www2.psy.uq.edu.au/~ftp/Crypto/ provides information on SSLeay and SSL, such as a list of bugs discovered in some commercial implementations, which can be found at http://www2.psy.uq.edu.au/~ftp/ Crypto/ssleay/vendor-bugs.html. 5.6 Summary SSL supplies a relatively simple mechanism to protect exchanges between two points over TPC. The modular architecture of SSL allows the evolution of some parts of the protocol without affecting the whole structure. There-fore, it is possible to introduce new improved algorithms and to take into account the speci fi c requirements of national legislations. The technical evo-lution of SSL ended fi nally in TLS, a standard from the IETF that will be presented in the next chapter. During the Handshake, the client and the server negotiate the cipher suite and establish a shared secret (MasterSecret) and cryptology parameters. Data are segmented using the Record protocol; each fragment is encrypted indi-vidually with protection of its integrity. To protect against replay attacks or reordering attacks, computation of the MAC includes the sequence numbers of the fragments to be transmitted. The main computational load in SSL comes from the cryptography, par-ticularly during session establishment. The ephemeral Dif fi e–Hellman algo-rithm for key establishment is exceptionally costly and should be avoided if the perfect forward security is not absolutely necessary. Among the mea-sures used for load reduction are session resumption to avoid a new Hand-shake and use of accelerators. The latter solution, however, creates some dif fi culties, because SSL is not adapted to multipoint relations. Thus, the presence of additional machines between the client and the server to carry out the cryptographic operations adds new security risks. The same can be said for applications that involve several actors simultaneously, such as a client, a merchant, and a gateway with banking networks.
Index pages curate the most relevant extracts from our library of academic textbooks. They’ve been created using an in-house natural language model (NLM), each adding context and meaning to key research topics.
