DOCSLIB.ORG

Introduction to the Ssl Protocol Author

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Introduction to the Ssl Protocol Author VIDEO Intypedia009en LESSON 9: INTRODUCTION TO THE SSL PROTOCOL AUTHOR: PhD Alfonso Muñoz Muñoz PhD Telecommunications Engineer – Technical University of Madrid R&D Security Researcher T>SIC Group – UPM ALICE Hello and welcome to Intypedia. Today we will explain the basics of the SSL/TLS encryption protocol; a very important protocol for electronic commerce and secure Virtual Private Networks. This is a very interesting topic... Come along! 1. THE ORIGIN OF SSL ‐ ATTACKS TO DATA IDENTITY AND INTEGRITY BOB In the 90's, the company Netscape Communication—famous for making the Netscape Navigator Web browser—created and developed a method for providing secure communications over a network; the SSL (Secure Sockets Layer) standard protocol. ALICE This protocol is very useful because when we surf the Internet, many attacks can be made to the exchanged information (integrity and confidentiality) as well as attacks to the identity of persons or services we connect to (authentication), as we saw in Lesson 4. BOB Script Intypedia009en 1 That's right. In such cases, the use of the SSL protocol is very helpful. Unfortunately, it isn't always implemented and when users don't use it properly, it's easier to perform attacks without having to change the security measures defined therein. In telecommunication networks, like the Internet, these attacks are usually carried out through Man‐in‐the‐middle attacks (MITM). When integrity and authenticity procedures aren't enabled, it's possible to change or modify the information in transit and also to impersonate the sender or receiver of the communication. Nowadays, such attacks are very easy to carry out using free tools available on the Internet. A recent Man‐in‐the‐middle attack famous for the publication of the Firesheep tool, consists of stealing a user's session cookie (the one that authenticates) when the user logs into a Web service like Facebook, Twitter or a Google account. ALICE Wow! And how is that possible? BOB It's possible when the attacker has access to the exchanged traffic—when they are in the same wireless network, for example—and when the data can be read easily. Once they have the session cookie that authenticates the user, they can impersonate the user and enter the sites that this validation provides access to. The attack based on stealing a session cookie—the HTTP session hijacking attack—has been known for a long time, but the Firesheep tool, a Firefox browser extension developed by Eric Butler in October 2010, shows that these attacks are very common nowadays. Interestingly, this incident prompted some companies to enable the SSL protocol for accessing their services securely. A significant example of this was Facebook. Maybe they hadn't considered it before because of its complexity, cost and that it would slow down the communications. ALICE How fascinating! So how does this protocol work? BOB Interesting question, Alice. Now we're going to explain it in detail. 2. HOW SSL WORKS – THE SSL HANDSHAKE PROTOCOL BOB SSL (Secure Sockets Layer) is a cryptographic protocol that provides authentication, integrity and confidentiality of the information in a client/server communication over a network, like Script Intypedia009en 2 the Internet. It runs in a layer between the application protocols such as HTTP, SMTP or NNTP and the TCP transport protocol. Today it is also possible to implement it on UDP. Usually, it is configured so that the communication server is authenticated while the client remains unauthenticated. This is typical, for example, when we connect to our bank's online website through https, where the s for security means that the SSL protocol is being used. Mutual authentication of client and server is also possible using this protocol. ALICE I have a question, Bob: I've heard that a protocol called TLS is also used for these purposes. Are SSL and TLS the same thing? BOB Good question, Alice, because many people are confused about this. The SSL protocol has been the basis for developing the TLS (Transport Layer Security) protocol, currently in version 1.2 (also known as SSL 3.3) defined in RFC 5246. SSL and TLS are conceptually similar, only that TLS enhances the classic SSL in some aspects such as protecting against further attacks, providing new cryptographic algorithms, avoiding the forced use of more vulnerable versions of the protocol, and so on. Apart from agreeing on the version of the protocol in order to establish the communication with the integrity, confidentiality and authenticity requirements, it is also necessary to agree in advance upon the security parameters that will enable a secure communication. These phases are performed by the SSL/TLS Handshake Protocol. However, we mustn't forget about another important protocol: the SSL/TLS Record Protocol that specifies how to encapsulate the sent and received data, and even the negotiation data. ALICE I see you've studied the subject. Could you explain how the SSL Handshake Protocol works? BOB This protocol focuses on three things: First, the client and server negotiation of the algorithms that will be used in the communication. Some of the cryptographic algorithms used for encryption, key exchange and signing are: 3DES, IDEA, AES, RSA, Diffie‐Hellman, DSA, SHA‐2. Second, the exchange of keys and the authentication based on digital certificates, using, whenever necessary, a validation through Public Key Infrastructure (PKI). And third, the encryption of traffic using symmetric cryptography. A session key is generated for communication based on the negotiated parameters, thus enabling the encryption of the data. As mentioned in previous lessons, symmetric cryptography is fast and requires less hardware resources, which is ideal when it is running on client, which usually has fewer resources than the server. Asymmetric cryptography is only used for key exchange and signing. Therefore, this protocol is a good example of the usefulness of hybrid ciphering. Script Intypedia009en 3 The secure connection begins once the parameters have been negotiated. But if the negotiation fails in any of its stages, the connection is cancelled. Let's take a look at an example where only the server is authenticated by its certificate. The following are the most important messages exchanged in the negotiation until the communication is established by means of a simple TLS handshake. 1. The client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number and a list of authentication, ciphering, MAC (Message Authentication Code) and compression algorithms. 2. The server responds with a ServerHello message, containing the selected protocol version (the highest supported by client and server), a random number, the chosen algorithms from those sent by the client and its digital certificate (using a Certificate message) to authenticate itself. 3. The client verifies the server's certificate through a trusted authority or a PKI. Then, the client answers with a ClientKeyExchange message containing a PreMasterSecret (a secret number) with information to generate the session key. If the RSA algorithm is used, the message will be encrypted with the server's public key and the random number generated by the client will have 48 bytes. 4. The client and server use the exchanged random numbers and the PreMasterSecret (retrieved by the server using its private key). With this data they compute a common secret called the master secret. All the subkeys for this connection are derived from the master secret by means of the established pseudorandom function. 5. The client now sends a ChangeCipherSpec record and tells the server that from that moment on, all the exchanged information will be authenticated and—if established previously by the server—it will also be encrypted. 6. Finally, the client sends a signed and encrypted Finished message, containing a hash and MAC of the messages negotiated previously. 7. The server then decrypts the Finished message sent by the client and verifies the hash and MAC. If the decryption or verification fails, the connection doesn't go through. 8. If everything goes well, the server sends a ChangeCipherSpec to the client indicating that, from that moment on, everything it sends will be signed and—if encryption was previously negotiated—encrypted. The server then sends a signed and encrypted Finished message containing a hash and MAC of the messages negotiated previously, which is then validated by the client. 9. The negotiation phase ends and the client and server can now exchange authenticated (and encrypted, if encryption was negotiated) messages. ALICE How interesting! And all of this is done in a transparent way for the user. Script Intypedia009en 4 3. APPLICATION OF THE SSL PROTOCOL – E‐COMMERCE AND VPNs BOB There is no doubt that the success of the SSL/TLS protocol is due to the expansion of electronic commerce on the Internet. Most financial institutions advocate its use: Visa, MasterCard, and American Express, just to name a few. Today it is hard to think of secure Internet communications without the use of SSL, digital certificates and public key infrastructures. A clear example is the securing of Web traffic, where https is used instead of http. SSL can also be used to tunnel an entire network and create a Virtual Private Network (VPN). This can be achieved with the open software tool OpenVPN, for instance. It provides a point‐ to‐point connection with hierarchical validation of remotely connected users and hosts, among other benefits. It is also widely used to provide authentication and encryption in voice over IP traffic (VoIP), that is, voice transmitted over the Internet using the IP network protocol. ALICE From what you have told me, I understand that since the SSL protocol is above the transport layer and below the application layer, with this protocol it would be possible to secure the communication between any software.
Load more

Recommended publications
  • Designing Secure Systems That People Can
    15- SSL, PKIs, and Secure Communication Engineering & Public Policy Lorrie Cranor, Blase Ur, and Rich Shay March 3, 2015 05-436 / 05-836 / 08-534 / 08-734 Usable Privacy and Security 1 Today! • An introduction to SSL/TLS • An introduction to PKIs • Recent developments in this area • Usability issues • An activity to make it better 2 Overview • Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS) enable secure communication • Frequently encountered with web browsing (HTTPS) and more behind the scenes in app, VOIP, etc. 3 What we want to defend against • People snooping on our communications – The contents of what we’re sending – Session tokens (see, e.g., Firesheep) • Man-in-the-middle attacks – We want to authenticate that we are talking to the right site, not an imposter – Use certificates inside a public-key infrastructure 4 How we could obtain trust • Web of trust – People you already trust introduce you to people they trust – Can get complicated, doesn’t scale well – Less frequently seen in practice • Public-Key Infrastructure (PKI) – Certificates are issued by certificate authorities that bind cryptographic keys to identities 5 Public-Key Infrastucture • Binding of keys to identities can be done automatically or by humans 6 What does SSL look like to users? • Compare, e.g., the following: – https://www.google.com (normal certificate) – Go to Google images and then click on an image and see what happens (mixed content) – https://otalliance.org (EV certificate) 7 What does PKI look like to browsers? • Hundreds
    [Show full text]
  • Certificate Authority – Registration Authority (Verifies Cert Requests) – Validation Authority (Handles Revocation)
    11. Trust on the Web Blase Ur and David Cash February 5th, 2020 CMSC 23200 / 33250 Overview • Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS) enable secure communication • Frequently encountered with web browsing (HTTPS) and more behind the scenes in app, VOIP, etc. What we want to defend against • People snooping on our communications – The contents of what we’re sending – Session tokens (see, e.g., Firesheep) • Person-in-the-middle attacks – We want to authenticate that we are talking to the right site, not an imposter – Use certificates inside a public-key infrastructure How we could obtain trust • Web of trust – People you already trust introduce you to people they trust – Can get complicated, doesn’t scale well – Infrequently seen in practice • Public-Key Infrastructure (PKI) – Certificates are issued by certificate authorities that bind cryptographic keys to identities Public-Key Infrastucture • Binding of keys to identities – Certificate authority – Registration authority (verifies cert requests) – Validation authority (handles revocation) Image from Wikimedia Foundation What does SSL look like to users? • Compare, e.g., the following: – https://www.google.com (normal certificate) – Go to Google images and then click on an image and see what happens (mixed content) – https://www.thawte.com (EV certificate) What does SSL look like to users? (From Felt et al. SOUPS 2016) How does PKI look to browsers? • Hundreds of trusted certificate authorities – Certificate authorities (CAs) sign the certificates binding
    [Show full text]
  • Understanding Flaws in the Deployment and Implementation of Web Encryption
    Understanding Flaws in the Deployment and Implementation of Web Encryption Suphannee Sivakorn Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Graduate School of Arts and Sciences COLUMBIA UNIVERSITY 2018 © 2018 Suphannee Sivakorn All rights reserved ABSTRACT Understanding Flaws in the Deployment and Implementation of Web Encryption Suphannee Sivakorn In recent years, the web has switched from using the unencrypted HTTP protocol to using encrypted communications. Primarily, this resulted in increasing deployment of TLS to mitigate information leakage over the network. This development has led many web service operators to mistakenly think that migrating from HTTP to HTTPS will magically protect them from information leakage without any additional effort on their end to guar- antee the desired security properties. In reality, despite the fact that there exists enough infrastructure in place and the protocols have been “tested” (by virtue of being in wide, but not ubiquitous, use for many years), deploying HTTPS is a highly challenging task due to the technical complexity of its underlying protocols (i.e., HTTP, TLS) as well as the complexity of the TLS certificate ecosystem and this of popular client applications suchas web browsers. For example, we found that many websites still avoid ubiquitous encryption and force only critical functionality and sensitive data access over encrypted connections while allowing more innocuous functionality to be accessed over HTTP. In practice, this approach is prone to flaws that can expose sensitive information or functionality tothird parties. Thus, it is crucial for developers to verify the correctness of their deployments and implementations.
    [Show full text]
  • HTTP Cookie Hijacking in the Wild: Security and Privacy Implications Suphannee Sivakorn*, Jason Polakis* and Angelos D
    HTTP Cookie Hijacking in the Wild: Security and Privacy Implications Suphannee Sivakorn*, Jason Polakis* and Angelos D. Keromytis [suphannee, polakis, angelos]@cs.columbia.edu Columbia University, New York NY, USA *Joint primary authors The widespread demand for online privacy, also fueled by widely-publicized demonstrations of session hijacking attacks against popular websites, has spearheaded the increasing deployment of HTTPS. However, many websites still avoid ubiquitous encryption due to performance or compatibility issues. The prevailing approach in these cases is to force critical functionality and sensitive data access over encrypted connections, while allowing more innocuous functionality to be accessed over HTTP. In practice, this approach is prone to flaws that can expose sensitive information or functionality to third parties. In this work, we conduct an in-depth assessment of a diverse set of major websites and explore what functionality and information is exposed to attackers that have hijacked a user’s HTTP cookies. We identify a recurring pattern across websites with partially deployed HTTPS; service personalization inadvertently results in the exposure of private information. The separation of functionality across multiple cookies with different scopes and inter-dependencies further complicates matters, as imprecise access control renders restricted account functionality accessible to non-session cookies. Our cookie hijacking study reveals a number of severe flaws; attackers can obtain the user’s home and work address and visited websites from Google, Bing and Baidu expose the user’s complete search history, and Yahoo allows attackers to extract the contact list and send emails from the user’s account. Furthermore, e-commerce vendors such as Amazon and Ebay expose the user’s purchase history (partial and full respectively), and almost every website exposes the user’s name and email address.
    [Show full text]
  • WEB BROWSER ATTACKS WEB BROWSER ATTACKS Introduction
    WEB BROWSER ATTACKS WEB BROWSER ATTACKS Introduction ................................................................................................................................................. 4 What is Web Browser? ................................................................................................................................ 4 Mozilla Firefox ......................................................................................................................................... 5 Google Chrome ........................................................................................................................................ 6 Apple Safari .............................................................................................................................................. 7 Enumerating Web Browsers ........................................................................................................................ 7 Using HTTP Headers ................................................................................................................................. 8 Using DOM Properties ........................................................................................................................... 11 What is HTTP/2? ........................................................................................................................................ 12 Is this actually good? .............................................................................................................................
    [Show full text]
  • Web Service Security with TLS
    Network Security in Practice Web Service Security with TLS by Martin Kreichgauer, Daniel Taschik & Johan Uhle Potsdam, March 2013 Supervisor Feng Cheng, HPI Contents Contents 1. Introduction 1 2. Introduction to Web Service Security1 2.1. Security Goals . .1 2.2. Threat Model . .2 2.3. Firesheep . .2 3. Introduction to Transport Layer Security3 3.1. Architecture . .3 3.1.1. X.509 . .5 3.1.2. Certificate Verification . .6 3.2. History . .7 3.3. Implementations . .8 4. Security of TLS 8 4.1. Introduction . .8 4.2. Server-side Configuration Issues . .9 4.2.1. Circumventing Encryption with sslstrip . 11 4.3. Client-side Implementation Issues . 13 4.3.1. Overview . 13 4.3.2. A MITM attack on an HTTPS Connection . 13 4.4. Cryptographic attacks . 15 4.5. Authenticity Framework . 16 4.5.1. Convergence . 16 4.5.2. Public Key Pinning . 16 5. Best Practices for TLS 17 5.1. Server Configuration . 17 5.1.1. Private Key length . 17 5.1.2. Supported TLS versions . 18 5.1.3. Cipher suites . 18 5.1.4. Redirects . 18 5.1.5. HTTP Strict Transport Security . 19 5.2. Blackbox Testing . 20 5.3. Client-side Considerations . 20 6. Conclusion 21 A. Firesheep Handlers 22 ii 1. Introduction 1. Introduction In recent decades, the World Wide Web has gained exceptional importance in the life of peo- ple. For many, it became the main source of information, main means of communication with their friends and family and core part of their daily work. But since the web became this valuable asset, it also attracts malevolent actors.
    [Show full text]
  • The Cracked Cookie Jar: HTTP Cookie Hijacking and the Exposure of Private Information
    The Cracked Cookie Jar: HTTP Cookie Hijacking and the Exposure of Private Information Suphannee Sivakorn∗, Iasonas Polakis∗ and Angelos D. Keromytis Department of Computer Science Columbia University, New York, USA fsuphannee, polakis, [email protected] ∗Joint primary authors Abstract—The widespread demand for online privacy, also the necessity of securing web connections from prying eyes. fueled by widely-publicized demonstrations of session hijacking The publicity garnered by the Firesheep extension [1], which attacks against popular websites, has spearheaded the increasing demonstrated how easily attackers can hijack a user’s session, deployment of HTTPS. However, many websites still avoid ubiq- uitous encryption due to performance or compatibility issues. The was a catalyst in expediting migration of critical user activity prevailing approach in these cases is to force critical functionality to mandatory HTTPS connections in major services (e.g., and sensitive data access over encrypted connections, while transmitting user credentials during the log-in process). allowing more innocuous functionality to be accessed over HTTP. Nonetheless, many major websites continue to serve content In practice, this approach is prone to flaws that can expose over unencrypted connections, which exposes the users’ HTTP sensitive information or functionality to third parties. In this paper, we conduct an in-depth assessment of a diverse cookies to attackers monitoring their traffic. Not enforcing set of major websites and explore what functionality and infor- ubiquitous encrypted connections may be attributed to various mation is exposed to attackers that have hijacked a user’s HTTP reasons, ranging from potential increases to infrastructure costs cookies. We identify a recurring pattern across websites with and the loss of in-network functionality [2] to maintaining partially deployed HTTPS; service personalization inadvertently support for legacy clients.
    [Show full text]
  • Firesheep and Sidejacking and Firesheep White Paper White
    Firesheep and Sidejacking and Firesheep White Paper White WHITE PAPER: FIRESHEEP AND SIDEJACKING White Paper: Firesheep and Sidejacking Firesheep and Sidejacking CONTENTS Introduction ............................................................ 3 The Problem of Unsecured Wi-Fi .......................................... 3 Self-Protection.......................................................... 4 The Solution: TLS/SSL Site Wide . 5 Costs vs. Benefits of TLS/SSL............................................. 5 Conclusion.............................................................. 6 2 White Paper: Firesheep and Sidejacking Introduction The recent release of the Firesheep Wi-Fi attack tool has increased awareness among both users and attackers of the inherent insecurity of unprotected HTTP connections. Users on unprotected networks who connect to websites through plain HTTP connections expose their connections to those sites to open surveillance and full compromise. Firesheep allows an attacker connected to the local network to monitor the web sessions of other users on that network. The attacker can then also commandeer the sessions of others, acting in their user context. Firesheep specifically targets open Wi-Fi networks, but the problem is the same on conventional wired Ethernet networks. None of this is new. These problems have been generally known, at least in the security community, for years. Firesheep has opened the vulnerability up to others and put devastating identity theft attacks in easy reach of even casual hackers. As experts proclaimed in reaction to Firesheep, the best solution to the problem is to use TLS/SSL for all connections to websites, including the home page. Perhaps owing to the increased need for processing power it would entail, many large sites have been sparing in their use of TLS/SSL, but such frugality is increasingly indefensible in the face of the level of threats and true costs.
    [Show full text]
  • Protecting Your Website with Always on SSL
    Protecting Your Website with Always On SSL Protecting Your Website With Always On SSL Developing and advocating best practices to mitigate emerging privacy, identity and security threats to online services, government agencies, organizations and consumers, thereby enhancing online trust and confidence and the vitality of the digital economy. Updated May 1, 2012 © 2012 Online Trust Alliance (OTA) All Rights Reserved Page 1 Protecting Your Website with Always On SSL Table of Contents EXECUTIVE SUMMARY ............................................................................................................... 3 THE NEED FOR PERSISTENT PROTECTION ONLINE ............................................................. 4 HTTP AND INSECURE COOKIES LEAVE USERS VULNERABLE TO ATTACK ........................................ 4 SESSION HIJACKING HAS BECOME DANGEROUSLY EASY ............................................................... 4 NOT JUST A COFFEE SHOP PROBLEM ........................................................................................... 5 USER EDUCATION ALONE IS NOT ENOUGH .................................................................................... 6 PROTECTING THE ENTIRE USER EXPERIENCE WITH ALWAYS ON SSL ............................ 6 EVERYONE ELSE IS DOING IT, AND SO SHOULD YOU ..................................................................... 6 FACEBOOK .................................................................................................................................. 7 GOOGLE .....................................................................................................................................
    [Show full text]
  • Network Analysis with Open Source Packet Analyzers - Case: Wireshark
    Bachelor's thesis (TUAS) Information Technology Network Technology 2016 Jeewan Bhusal NETWORK ANALYSIS WITH OPEN SOURCE PACKET ANALYZERS - CASE: WIRESHARK BACHELOR'S THESIS | ABSTRACT TURKU UNIVERSITY OF APPLIED SCIENCES Information Technology | Network Technology May 2016 | 72 Instructor: Ossi Väänänen Jeewan Bhusal NETWORK ANALYSIS WITH OPEN SOURCE PACKET ANALYZERS CASE: WIRESHARK Computer Network is a growing field every day. Networking has made life easy. This world-wide computer network is accessed by more than 3 billion people in the world. The growth rate is quick and this shows the complexity of internet world. The defense research of USA gave birth to ARPANET which later created protocols to link two different computers. This creation is called TCP/IP protocols and this is how internet was born. Computers are connected to different topologies in a network and they communicate because of networks protocols. Small home, office network, local area network (LAN) of computers then become linked with Wide area networks (WAN). In this thesis, architecture of computer networks together with analysis of packet is studied. Packet analysis is carried out with the open packet analyzer software “Wireshark”. This thesis also focuses on security challenges for a network and also presents some solutions. Wireshark can play an important role to keep the network secure and fully operational. Wireshark helps analyzing network, protocols, troubleshooting network and preventing attacks. KEYWORDS: Wireshark, TCP/IP, Packet analyzer, computer network,
    [Show full text]
  • Analysis of Http Cookie Hijacking in the Wild
    International Journal of Innovative Technology and Exploring Engineering (IJITEE) ISSN: 2278-3075, Volume-9 Issue-7, May 2020 Analysis of Http Cookie Hijacking in the Wild K.Samhitha, K.Tharun, P.Likhith, T.Srinivasarao Abstract: Because cookies act as the sole evidence of user There are a number of explanations for failing to introduce identification, web sessions are especially vulnerable to attacks all-around secure communications, ranging from the through session hijacking, where the server operated by a specific possible changes of bandwidth costs and the lack of in- user sends users ' identity requests. If n > 1 cookies are used to network functionality of retaining conventional customer execute a session, n sub-sessions that actually run on the same service. If policies of access control properly distinguish website where the individual cookies are used to access part of the session's state details. Our cookie hijacking analysis shows a authenticated rights (e.g., session cookies) and range of significant defects; attackers may reach Google's home unauthenticated cookies (e.g., persistent cookies for address and work address and websites that are accessed by Bing tracking) instead stolen HTTP cookies will preclude or Baidu, show the entire browsing history of the user, and attackers from gathering some personal data. For reality, Yahoo enables attackers to delete the list of contacts and upload though, it is not and things are getting worse as systems tend emails from the account of the consumer. For fact, e-commerce to lose protection on usability. Website rights HTTP providers such as Amazon and Ebay have a limited, complete cookies, which boost customer functionality, to personalize customer order background, so almost all platforms have a user the services, but prohibit demands for re-authentication, name so e-mail address on their page.
    [Show full text]
  • UNAUTHORIZED ACCESS ––––––––––––––––––––––––––––––––––––––––––––––––– the Crisis in Online Privacy and Security
    UNAUTHORIZED ACCESS ––––––––––––––––––––––––––––––––––––––––––––––––– The Crisis in Online Privacy and Security UNAUTHORIZED ACCESS ––––––––––––––––––––––––––––––––––––––––––––––––– The Crisis in Online Privacy and Security Robert H. Sloan • Richard Warner Boca Raton London New York CRC Press is an imprint of the Taylor & Francis Group, an informa business A CHAPMAN & HALL BOOK CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 First issued in hardback 2017 © 2014 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works ISBN: 978-1-4398-3013-0 (pbk) ISBN: 978-1-138-43692-3 (hbk) This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint. The Open Access version of this book, available at www.taylorfrancis.com, has been made available under a Creative Commons Attribution-Non Commercial-No Derivatives 4.0 license. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe. Library of Congress Cataloging-in-Publication Data Sloan, Robert H.
    [Show full text]