DOCSLIB.ORG

More Tricks for Defeating SSL in Practice

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

More Tricks For Defeating SSL In Practice Moxie Marlinspike [email protected] Moxie Marlinspike Institute For Disruptive Studies Moxie Marlinspike Institute For Disruptive Studies Once Again, The Back Story... Moxie Marlinspike Institute For Disruptive Studies In the past, I've talked about BasicConstraints... Moxie Marlinspike Institute For Disruptive Studies Certificate Chaining VeriSign Intermediate CA paypal.com Moxie Marlinspike Institute For Disruptive Studies Certificate Chaining VeriSign Intermediate CA Intermediate CA paypal.com Moxie Marlinspike Institute For Disruptive Studies How do we verify these things? Moxie Marlinspike Institute For Disruptive Studies What they say: ● Verify that the name of the leaf node is the same as the site you're connecting to. ● Verify that the leaf certificate has not expired. ● Check the signature. ● If the signing CA is in our list of trusted root CAs, stop. Otherwise, move one up the chain and repeat. Moxie Marlinspike Institute For Disruptive Studies Here Be Dragons ● Very tempting to use a simple recursive function. ● Everyone focuses on the signature validation. ● The result of a naïve attempt at validation is a chain that is complete, but nothing more. Moxie Marlinspike Institute For Disruptive Studies What if... VeriSign Intermediate CA Intermediate CA thoughtcrime .org Moxie Marlinspike Institute For Disruptive Studies What if... VeriSign Intermediate CA Intermediate CA thoughtcrime .org paypal.com Moxie Marlinspike Institute For Disruptive Studies What they say: ● Verify that the name of the leaf node is the same as the site you're connecting to. ● Verify that the leaf certificate has not expired. ● Check the signature. ● If the signing CA is in our list of trusted root CAs, stop. Otherwise, move one up the chain and repeat. Moxie Marlinspike Institute For Disruptive Studies Something must be wrong, but... ● All the signatures are valid. ● Nothing has expired. ● The chain is in tact. ● The root CA is embedded in the browser and trusted. Moxie Marlinspike Institute For Disruptive Studies But we just created a valid certificate for PayPal, and we're not PayPal? Moxie Marlinspike Institute For Disruptive Studies The missing piece... Moxie Marlinspike Institute For Disruptive Studies ...is a somewhat obscure field. Moxie Marlinspike Institute For Disruptive Studies Back In The Day ● Most CAs didn't explicitly set basicConstraints: CA=False ● Whether the field was there or not, most SSL implementations didn't bother to check it. ● Anyone with a valid leaf node certificate could create and sign a leaf node certificate for any other domain. ● When presented with a complete chain, IE, Outlook, Konqueror, OpenSSL, and others considered it valid... Moxie Marlinspike Institute For Disruptive Studies And then in 2002... ● Microsoft did something particularly annoying, so I blew this up by publishing it. ● Microsoft claimed that it was impossible to exploit. ● So I also published the tool that exploits it. Moxie Marlinspike Institute For Disruptive Studies sslsniff Moxie Marlinspike Institute For Disruptive Studies sslsniff Moxie Marlinspike Institute For Disruptive Studies sslsniff sslsniff ● Intercept a connection from ● Make a normal SSL the client side. connection to the server. ● Generate a certificate for the ● Pass data between client and site it is connecting to. server, decrypting and ● Sign it with any random valid encrypting on each end. leaf node certificate. ● Pass that certificate chain to the client. Moxie Marlinspike Institute For Disruptive Studies Lately, I've been talking about SSL Stripping... Moxie Marlinspike Institute For Disruptive Studies brief Moxie Marlinspike Institute For Disruptive Studies Moxie Marlinspike Institute For Disruptive Studies SSL can be useful, but how it's deployed matters Moxie Marlinspike Institute For Disruptive Studies In the context of web browsing ● SSL is almost never encountered directly. ● It is either encountered as a result of: ● A 302 redirect from an HTTP URL to an HTTPS URL. ● An HTTPS link that a user clicks on from an HTTP page. – (Think, “My Cart,” “Checkout,” “Login,” etc...) Moxie Marlinspike Institute For Disruptive Studies Moxie Marlinspike Institute For Disruptive Studies Moxie Marlinspike Institute For Disruptive Studies We Can Attack SSL Before We Even Get There Moxie Marlinspike Institute For Disruptive Studies sslsniff Moxie Marlinspike Institute For Disruptive Studies sslstrip Moxie Marlinspike Institute For Disruptive Studies sslstrip ● Watch HTTP traffic go by. ● Switch <a href=”https://...”> to <a href=”http://...”> ● and keep a map of what you've changed. ● Switch Location: https:// to Location: http:// ● and keep a map of what you've changed. sslstrip Moxie Marlinspike Institute For Disruptive Studies sslstrip ● Watch HTTP traffic go by. ● When we see an HTTP request for a URL that we've stripped, proxy that out as HTTPS to the server. ● Watch the HTTPS traffic go by, log everything that we want, and keep a map of all relative, CSS, and JS links that go by. sslstrip Moxie Marlinspike Institute For Disruptive Studies How Does It Look? How Does It Look? How Does It Look? How Does It Look? Where can we go from here? Moxie Marlinspike Institute For Disruptive Studies Where do we need to go from here? Moxie Marlinspike Institute For Disruptive Studies What's with certificates, anyways? X509Certificate Version Serial Number Issuer Validity (not before X or after Y) Subject PublicKey SignatureAlgorithm Signature Moxie Marlinspike Institute For Disruptive Studies What's with certificates, anyways? X509Certificate Version Serial Number Issuer Validity (not before X or after Y) Subject PublicKey SignatureAlgorithm Signature Moxie Marlinspike Institute For Disruptive Studies What's with certificates, anyways? X509Certificate Version Serial Number Issuer Validity (not before X or after Y) Subject PublicKey SignatureAlgorithm Signature Moxie Marlinspike Institute For Disruptive Studies What's with certificates, anyways? X509Certificate Version Serial Number Issuer Validity (not before X or after Y) Subject PublicKey SignatureAlgorithm Signature Moxie Marlinspike Institute For Disruptive Studies What's with certificates, anyways? X509Certificate Version Serial Number Issuer Validity (not before X or after Y) Subject PublicKey SignatureAlgorithm Signature Moxie Marlinspike Institute For Disruptive Studies Moxie Marlinspike Institute For Disruptive Studies The Big Three ● Secrecy ● Authenticity ● Integrity Moxie Marlinspike Institute For Disruptive Studies SSL/TLS Handshake Beginnings ClientHello ServerHello, ServerCertificate Moxie Marlinspike Institute For Disruptive Studies SSL Handshake Beginnings X509Certificate Version Serial Number Issuer Validity Subject PublicKey SignatureAlgorithm Signature Moxie Marlinspike Institute For Disruptive Studies The Problems For Us Begin Attacker ClientHello ServerHello, ServerCertificate? Moxie Marlinspike Institute For Disruptive Studies Let's start by looking back once more. Moxie Marlinspike Institute For Disruptive Studies In 2000, things were different. Moxie Marlinspike Institute For Disruptive Studies Notaries! Moxie Marlinspike Institute For Disruptive Studies Identification! Moxie Marlinspike Institute For Disruptive Studies Phone Calls! Moxie Marlinspike Institute For Disruptive Studies Actual people involved... Moxie Marlinspike Institute For Disruptive Studies That is a bygone era Moxie Marlinspike Institute For Disruptive Studies These days it's all about: online domain validation Moxie Marlinspike Institute For Disruptive Studies Moxie Marlinspike Institute For Disruptive Studies Moxie Marlinspike Institute For Disruptive Studies PKCS #10 CertificateRequest Version Subject PublicKey Attributes Moxie Marlinspike Institute For Disruptive Studies PKCS #10 CertificateRequest Version Subject PublicKey Attributes Moxie Marlinspike Institute For Disruptive Studies PKCS #10 CertificateRequest Version Subject www.bankofamerica.com PublicKey Attributes Moxie Marlinspike Institute For Disruptive Studies PKCS #10 CertificateRequest Version Subject www.bankofamerica.com PublicKey Attributes Moxie Marlinspike Institute For Disruptive Studies PKCS #10 CertificateRequest Version Subject www.bankofamerica.com PublicKey Attributes WHOIS Lookup Moxie Marlinspike Institute For Disruptive Studies PKCS #10 CertificateRequest Version Subject www.bankofamerica.com PublicKey Attributes WHOIS Lookup Email [email protected] Moxie Marlinspike Institute For Disruptive Studies PKCS #10 CertificateRequest Version Subject www.bankofamerica.com PublicKey Attributes Moxie Marlinspike Institute For Disruptive Studies PKCS #10 CertificateRequest Version Subject www.bankofamerica.com PublicKey Attributes Moxie Marlinspike Institute For Disruptive Studies PKCS #10 CertificateRequest Version Subject certificate.authoritie s.are.a.total.ripoff. PublicKey bankofamerica.com Attributes Moxie Marlinspike Institute For Disruptive Studies PKCS #10 CertificateRequest Version Subject certificate.authoritie s.are.a.total.ripoff. PublicKey bankofamerica.com Attributes Moxie Marlinspike Institute For Disruptive Studies Subjects DistinguishedName Country State Locale Organization Organizational Unit Common Name Moxie Marlinspike Institute For Disruptive Studies Subjects ● The X.509 standard is DistinguishedName a total nightmare. Country ● Three revisions, State twenty years. Locale ● Parts of the standard Organization have literally been Organizational Unit “lost” and then later Common Name “found” again.
Recommended publications
  • Universidad Pol Facultad D Trabajo

    Universidad Pol Facultad D Trabajo

    UNIVERSIDAD POLITÉCNICA DE MADRID FACULTAD DE INFORMÁTICA TRABAJO FINAL DE CARRERA ESTUDIO DEL PROTOCOLO XMPP DE MESAJERÍA ISTATÁEA, DE SUS ATECEDETES, Y DE SUS APLICACIOES CIVILES Y MILITARES Autor: José Carlos Díaz García Tutor: Rafael Martínez Olalla Madrid, Septiembre de 2008 2 A mis padres, Francisco y Pilar, que me empujaron siempre a terminar esta licenciatura y que tanto me han enseñado sobre la vida A mis abuelos (q.e.p.d.) A mi hijo icolás, que me ha dejado terminar este trabajo a pesar de robarle su tiempo de juego conmigo Y muy en especial, a Susana, mi fiel y leal compañera, y la luz que ilumina mi camino Agradecimientos En primer lugar, me gustaría agradecer a toda mi familia la comprensión y confianza que me han dado, una vez más, para poder concluir definitivamente esta etapa de mi vida. Sin su apoyo, no lo hubiera hecho. En segundo lugar, quiero agradecer a mis amigos Rafa y Carmen, su interés e insistencia para que llegara este momento. Por sus consejos y por su amistad, les debo mi gratitud. Por otra parte, quiero agradecer a mis compañeros asesores militares de Nextel Engineering sus explicaciones y sabios consejos, que sin duda han sido muy oportunos para escribir el capítulo cuarto de este trabajo. Del mismo modo, agradecer a Pepe Hevia, arquitecto de software de Alhambra Eidos, los buenos ratos compartidos alrrededor de nuestros viejos proyectos sobre XMPP y que encendieron prodigiosamente la mecha de este proyecto. A Jaime y a Bernardo, del Ministerio de Defensa, por haberme hecho descubrir las bondades de XMPP.
  • Openfire Service Level Agreement

    Openfire Service Level Agreement

    Service Level Agreement Technical Services — Communications Service University Technology Services 1. Overview This Service Level Agreement (SLA) is between University Technology Services (UTS) and either departments or groups choosing to utilize the internal Oakland University instant messaging (OUIM) service. The OUIM service is currently referenced by talk.oakland.edu and runs XMPP/Jabber software called Openfire. Under this SLA, UTS agrees to provide specific information technology (IT) services. This SLA also covers performance and reliability targets and objectives. Section 7 requires the signature and contact information of the group coordinator as an agreement to the SLA. OUIM is an online service that is available on campus and off campus. The requirements to utilize the service are a NetID, an XMPP client, and an Internet connection. XMPP clients are available online. The UTS Helpdesk supports the XMPP clients Spark, Pidgin, and Adium. Instructions are available on the UTS Web site at http://www.oakland.edu/?id=13849&sid=70. 2. Purpose The purpose of this SLA is to establish a cooperative partnership between UTS staff members with the community of customers who may opt into its use by clarifying roles, setting expectations, and providing service objectives and limitations. 3. Terms of Agreement This service is provided on an ongoing basis. From time to time, it may be reviewed and modified by UTS. Modifications to this agreement will be done at the sole discretion of UTS and the Technical Support and Services team (TSS). 4. Service Hours Regularly scheduled maintenance will be scheduled during low-use hours as much as possible; such work will be done either before 8:00 A.M.
  • The Double Ratchet Algorithm

    The Double Ratchet Algorithm

    The Double Ratchet Algorithm Trevor Perrin (editor) Moxie Marlinspike Revision 1, 2016-11-20 Contents 1. Introduction 3 2. Overview 3 2.1. KDF chains . 3 2.2. Symmetric-key ratchet . 5 2.3. Diffie-Hellman ratchet . 6 2.4. Double Ratchet . 13 2.6. Out-of-order messages . 17 3. Double Ratchet 18 3.1. External functions . 18 3.2. State variables . 19 3.3. Initialization . 19 3.4. Encrypting messages . 20 3.5. Decrypting messages . 20 4. Double Ratchet with header encryption 22 4.1. Overview . 22 4.2. External functions . 26 4.3. State variables . 26 4.4. Initialization . 26 4.5. Encrypting messages . 27 4.6. Decrypting messages . 28 5. Implementation considerations 29 5.1. Integration with X3DH . 29 5.2. Recommended cryptographic algorithms . 30 6. Security considerations 31 6.1. Secure deletion . 31 6.2. Recovery from compromise . 31 6.3. Cryptanalysis and ratchet public keys . 31 1 6.4. Deletion of skipped message keys . 32 6.5. Deferring new ratchet key generation . 32 6.6. Truncating authentication tags . 32 6.7. Implementation fingerprinting . 32 7. IPR 33 8. Acknowledgements 33 9. References 33 2 1. Introduction The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key. Typically the parties will use some key agreement protocol (such as X3DH [1]) to agree on the shared secret key. Following this, the parties will use the Double Ratchet to send and receive encrypted messages. The parties derive new keys for every Double Ratchet message so that earlier keys cannot be calculated from later ones.
  • Security Analysis of the Signal Protocol Student: Bc

    Security Analysis of the Signal Protocol Student: Bc

    ASSIGNMENT OF MASTER’S THESIS Title: Security Analysis of the Signal Protocol Student: Bc. Jan Rubín Supervisor: Ing. Josef Kokeš Study Programme: Informatics Study Branch: Computer Security Department: Department of Computer Systems Validity: Until the end of summer semester 2018/19 Instructions 1) Research the current instant messaging protocols, describe their properties, with a particular focus on security. 2) Describe the Signal protocol in detail, its usage, structure, and functionality. 3) Select parts of the protocol with a potential for security vulnerabilities. 4) Analyze these parts, particularly the adherence of their code to their documentation. 5) Discuss your findings. Formulate recommendations for the users. References Will be provided by the supervisor. prof. Ing. Róbert Lórencz, CSc. doc. RNDr. Ing. Marcel Jiřina, Ph.D. Head of Department Dean Prague January 27, 2018 Czech Technical University in Prague Faculty of Information Technology Department of Computer Systems Master’s thesis Security Analysis of the Signal Protocol Bc. Jan Rub´ın Supervisor: Ing. Josef Kokeˇs 1st May 2018 Acknowledgements First and foremost, I would like to express my sincere gratitude to my thesis supervisor, Ing. Josef Kokeˇs,for his guidance, engagement, extensive know- ledge, and willingness to meet at our countless consultations. I would also like to thank my brother, Tom´aˇsRub´ın,for proofreading my thesis. I cannot express enough gratitude towards my parents, Lenka and Jaroslav Rub´ınovi, who supported me both morally and financially through my whole studies. Last but not least, this thesis would not be possible without Anna who re- lentlessly supported me when I needed it most. Declaration I hereby declare that the presented thesis is my own work and that I have cited all sources of information in accordance with the Guideline for adhering to ethical principles when elaborating an academic final thesis.
  • SSL/TLS Interception Proxies and Transitive Trust Jeff Jarmoc Dell Secureworks Counter Threat Unit℠ Threat Intelligence

    SSL/TLS Interception Proxies and Transitive Trust Jeff Jarmoc Dell Secureworks Counter Threat Unit℠ Threat Intelligence

    SSL/TLS Interception Proxies and Transitive Trust Jeff Jarmoc Dell SecureWorks Counter Threat Unit℠ Threat Intelligence Presented at Black Hat Europe – March 14, 2012. Introduction Secure Sockets Layer (SSL) [1] and its successor Transport Layer Security (TLS) [2] have become key components of the modern Internet. The privacy, integrity, and authenticity [3] [4] provided by these protocols are critical to allowing sensitive communications to occur. Without these systems, e- commerce, online banking, and business-to-business exchange of information would likely be far less frequent. Threat actors have also recognized the benefits of transport security, and they are increasingly turning to SSL to hide their activities. Advanced Persistent Threat (APT) attackers [5], botnets [6], and even commodity web attacks can leverage SSL encryption to evade detection. To counter these tactics, organizations are increasingly deploying security controls that intercept end- to-end encrypted channels. Web proxies, data loss prevention (DLP) systems, specialized threat detection solutions, and network intrusion prevention systems (NIPS) offer functionality to intercept, inspect, and filter encrypted traffic. Similar functionality is present in lawful intercept systems and solutions enabling the broad surveillance of encrypted communications by governments. Broadly classified as “SSL/TLS interception proxies,” these solutions act as a “man in the middle,” violating the end-to-end security promises of SSL. This type of interception comes at a cost. Intercepting SSL-encrypted connections sacrifices a degree of privacy and integrity for the benefit of content inspection, often at the risk of authenticity and endpoint validation. Implementers and designers of SSL interception proxies should consider these risks and understand how their systems operate in unusual circumstances.
  • Novell Messenger 3.0 May 2015

    Novell Messenger 3.0 May 2015

    Novell Messenger 3.0 May 2015 1Overview The information in this Readme file pertains to Novell Messenger 3.0. Novell Messenger 3.0 offers enhanced functionality over prior Messenger versions: Mobile Applications: Novell Messenger 3.0 provides native applications for iOS, Android, and BlackBerry devices. For more information, see “Using Novell Messenger on Your Mobile Device” in the Novell Messenger 3.0 Client User Guide. For information about the administrative tasks associated with Messenger mobile applications, see “Managing Messenger Mobile Applications” in the Novell Messenger 3.0 Administration Guide. Simultaneous Client Connections: Novell Messenger 3.0 allows you to maintain simultaneous connections to your Messenger system from multiple workstations or devices. For example, you can be connected to Messenger on your workstation, and then connect to Messenger from a mobile device without being logged out of Messenger on your workstation. For more information about this feature, see “Limiting Physical Access to Client Workstations” in “Securing Novell Messenger” in the Novell Messenger 3.0 Administration Guide. Update Clients (Look and Feel): Novell Messenger 3.0 provides an updated look and feel for both the Windows and Linux/Mac client interfaces. The Messenger 3.0 release also contains the following changes: Removal of NetWare support: With Messenger 3.0 and later, NetWare is no longer supported. ConsoleOne download option: If you have not already installed ConsoleOne, it is available with the Messenger distribution. 2 System Requirements Novell Messenger 3.0 system requirements (including requirements for mobile devices) are listed in “Novell Messenger Hardware and Software Requirements” in the Novell Messenger 3.0 Installation Guide.
  • Is Bob Sending Mixed Signals?

    Is Bob Sending Mixed Signals?

    Is Bob Sending Mixed Signals? Michael Schliep Ian Kariniemi Nicholas Hopper University of Minnesota University of Minnesota University of Minnesota [email protected] [email protected] [email protected] ABSTRACT Demand for end-to-end secure messaging has been growing rapidly and companies have responded by releasing applications that imple- ment end-to-end secure messaging protocols. Signal and protocols based on Signal dominate the secure messaging applications. In this work we analyze conversational security properties provided by the Signal Android application against a variety of real world ad- versaries. We identify vulnerabilities that allow the Signal server to learn the contents of attachments, undetectably re-order and drop messages, and add and drop participants from group conversations. We then perform proof-of-concept attacks against the application to demonstrate the practicality of these vulnerabilities, and suggest mitigations that can detect our attacks. The main conclusion of our work is that we need to consider more than confidentiality and integrity of messages when designing future protocols. We also stress that protocols must protect against compromised servers and at a minimum implement a trust but verify model. 1 INTRODUCTION (a) Alice’s view of the conversa-(b) Bob’s view of the conversa- Recently many software developers and companies have been inte- tion. tion. grating end-to-end encrypted messaging protocols into their chat applications. Some applications implement a proprietary protocol, Figure 1: Speaker inconsistency in a conversation. such as Apple iMessage [1]; others, such as Cryptocat [7], imple- ment XMPP OMEMO [17]; but most implement the Signal protocol or a protocol based on Signal, including Open Whisper Systems’ caching.
  • A User Study of Off-The-Record Messaging

    A User Study of Off-The-Record Messaging

    A User Study of Off-the-Record Messaging Ryan Stedman Kayo Yoshida Ian Goldberg University of Waterloo 200 University Avenue West Waterloo, Ontario, Canada N2L 3G1 {rstedman@cs, k2yoshid@math, iang@cs}.uwaterloo.ca ABSTRACT Keywords Instant messaging is a prevalent form of communication ac- OTR, Usable Security, Instant Messaging, Think Aloud ross the Internet, yet most instant messaging services pro- vide little security against eavesdroppers or impersonators. 1. INTRODUCTION There are a variety of existing systems that aim to solve There has been much research into creating privacy-en- this problem, but the one that provides the highest level hancing technologies, especially since the Internet has started of privacy is Off-the-Record Messaging (OTR), which aims to play an essential role in everyday life. However, not many to give instant messaging conversations the level of privacy of these technologies have seen widespread adoption. One available in a face-to-face conversation. In the most recent of the reasons for this is that many of these technologies redesign of OTR, as well as increasing the security of the provide insufficient usability [8]. protocol, one of the goals of the designers was to make OTR The process of evaluating and enhancing usability is im- easier to use, without users needing to understand details of portant in order for a privacy-enhancing technology to pro- computer security such as keys or fingerprints. vide benefits to ordinary users. Since privacy is not just To determine if this design goal has been met, we con- intended for computer scientists or cryptographers, but for ducted a user study of the OTR plugin for the Pidgin in- everyone, these technologies should be accessible to the gen- stant messaging client using the think aloud method.
  • A Survey of Open Source Products for Building a SIP Communication Platform

    A Survey of Open Source Products for Building a SIP Communication Platform

    Hindawi Publishing Corporation Advances in Multimedia Volume 2011, Article ID 372591, 21 pages doi:10.1155/2011/372591 Research Article A Survey of Open Source Products for Building a SIP Communication Platform Pavel Segec and Tatiana Kovacikova Department of InfoCom Networks, University of Zilina, Univerzitna 8215/1, 010 26 Zilina, Slovakia Correspondence should be addressed to Tatiana Kovacikova, [email protected] Received 29 July 2011; Revised 31 October 2011; Accepted 15 November 2011 Academic Editor: T. Turletti Copyright © 2011 P. Segec and T. Kovacikova. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. The Session Initiation Protocol (SIP) is a multimedia signalling protocol that has evolved into a widely adopted communication standard. The integration of SIP into existing IP networks has fostered IP networks becoming a convergence platform for both real- time and non-real-time multimedia communications. This converged platform integrates data, voice, video, presence, messaging, and conference services into a single network that offers new communication experiences for users. The open source community has contributed to SIP adoption through the development of open source software for both SIP clients and servers. In this paper, we provide a survey on open SIP systems that can be built using publically available software. We identify SIP features for service deve- lopment and programming, services and applications of a SIP-converged platform, and the most important technologies support- ing SIP functionalities. We propose an advanced converged IP communication platform that uses SIP for service delivery.
  • Implementing Reliable Instant Messaging at Your Library

    Implementing Reliable Instant Messaging at Your Library

    Implementing Reliable Instant Messaging at Your Library Karen McCoy Adult Services Librarian Farmington Public Library, NM Some background… More libraries are communicating with patrons in real time over the internet “Online real-time chat reference services have become increasingly prevalent in many types and sizes of libraries” (1). BUT… “Because no IM technology standard has been approved by all the major players, IM has long been problematic to libraries… but newer IM products can help resolve these dilemmas.”(2). 1. Kwon, Nahyun, & Gregory, Vicki L. (2007). The effects of librarians' behavioral performance on user satisfaction in chat reference services. Reference & User Services Quarterly. 47, 137-148, 137. 2. Rethlefsen, Melissa L. (Summer 2007). Product Pipeline. Netconnect, 14-16 Instant Messaging vs. Chat Software What’s the difference? Chat Software: fee-based, usually only used in businesses and libraries (usually part of a consortium to reduce cost) also referred to as “virtual reference” or “chat reference.” Instant Messaging: FREE to libraries and patrons, more often used by people in their daily lives, generally not platform dependent (1), more compatible in a Web 2.0 environment A recent trend in reference service seems to be a move from use of chat reference software to use of IM (2). 1. Johnson, Kris. “Pros & Cons of IM/SMS Virtual Reference.” NMLA/MPLA Presentation. March, 2007 2. Naylor, Sharon, Stoffel, Bruce, & Van Der Laan, Sharon (2008). Why isn't our chat reference used more? Reference & User Services Quarterly.
  • The Most Dangerous Code in the World: Validating SSL Certificates In

    The Most Dangerous Code in the World: Validating SSL Certificates In

    The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software Martin Georgiev Subodh Iyengar Suman Jana The University of Texas Stanford University The University of Texas at Austin at Austin Rishita Anubhai Dan Boneh Vitaly Shmatikov Stanford University Stanford University The University of Texas at Austin ABSTRACT cations. The main purpose of SSL is to provide end-to-end security SSL (Secure Sockets Layer) is the de facto standard for secure In- against an active, man-in-the-middle attacker. Even if the network ternet communications. Security of SSL connections against an is completely compromised—DNS is poisoned, access points and active network attacker depends on correctly validating public-key routers are controlled by the adversary, etc.—SSL is intended to certificates presented when the connection is established. guarantee confidentiality, authenticity, and integrity for communi- We demonstrate that SSL certificate validation is completely bro- cations between the client and the server. Authenticating the server is a critical part of SSL connection es- ken in many security-critical applications and libraries. Vulnerable 1 software includes Amazon’s EC2 Java library and all cloud clients tablishment. This authentication takes place during the SSL hand- based on it; Amazon’s and PayPal’s merchant SDKs responsible shake, when the server presents its public-key certificate. In order for transmitting payment details from e-commerce sites to payment for the SSL connection to be secure, the client must carefully verify gateways; integrated shopping carts such as osCommerce, ZenCart, that the certificate has been issued by a valid certificate authority, Ubercart, and PrestaShop; AdMob code used by mobile websites; has not expired (or been revoked), the name(s) listed in the certifi- Chase mobile banking and several other Android apps and libraries; cate match(es) the name of the domain that the client is connecting Java Web-services middleware—including Apache Axis, Axis 2, to, and perform several other checks [14, 15].
  • Release Notes 2021 Firmware Version Pcs21ba

    Release Notes 2021 Firmware Version Pcs21ba

    Spectralink DECT Server 2500 and 8000 Release Notes 2021 Firmware Version PCS21Ba Release Notes Spectralink Europe ApS, 2021 – R2 Bygholm Søpark 21E Stuen, Horsens, DK-8700, Denmark DECT Server 2500 and 8000 Release Notes Table of Contents Introduction ...................................................... 3 Changes ............................................................................. 5 Version PCS21Ba, 2021 – R2 ................................................................................................ 5 Version PCS21Ae, 2021 – R1 ................................................................................................ 5 Version PCS20Cd, 2020 – R3 ................................................................................................ 7 Version PCS20Ab, 2020 – R1 ................................................................................................ 8 Version PCS19Cb, 2019 – R3 .............................................................................................. 10 Version PCS19Bb, 2019 – R2 .............................................................................................. 12 Version PCS19Ab, 2019 – Q1 .............................................................................................. 13 Version PCS18Kb, 2018 – Q4 .............................................................................................. 14 Version PCS18Ka, 2018 (never released) ........................................................................... 15 Version PCS18Ea, 2018 – Q3 .............................................................................................