DOCSLIB.ORG

Secure Transport Protocols

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Secure Transport Protocols Practical cryptography Common Use scenarios Secure Transport Protocols After analyzing all the required cryptographic primitives (symmetric and asymmetric ciphers, hashes), we can tackle: 1 The TLS secure transport protocol (HTTPS and Secure Mail Alessandro Barenghi Transport) 2 The Secure SHell (SSH) protocol (secure interactive terminal access) Dipartimento di Elettronica, Informazione e Bioingegneria (DEI) 3 The Tor Onion Routing protocol (Transport anonymity) Politecnico di Milano In all cases the bulk of the data is encrypted with an ephemeral key alessandro.barenghi - at - polimi.it with a block cipher The ephemeral key is agreed via an asymmetric key cipher All protocols employ public key authentication mechanisms to provide authenticated connections G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 1 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 2 / 32 TLS - A brief history TLS (SSL) - Basics and Standards The SSL times Overview The Secure Socket Layer (SSL) protocol was designed in 1995 by Tal TLS v1.2 (RFC5246) employs a hybrid encryption scheme: ElGamal to provide transport security for HTTP over TCP. The first Public key ciphers are employed to provide endpoint authentication and public version was SSL 2.0 exchange securely an ephemeral session key Secret key ciphers are employed to provide high throughput data TLS - Birth and evolution transmission, employing the session key as a shared secret In 1999 the IETF standardized the first version of TLS, starting from X.509 certificates are employed to provide authentication to the SSL v3.0, and fixing some security issues which were persisting since communication endpoints to avoid impersonation attacks SSL v2.0 (SSL and TLS are not interoperable) The TLS transport layer provides no enforced integrity guarantee, TLS was updated three times since then (v1.1, v1.2, v1.3) save when the mode of operation of the symmetric cipher does so The most widespread version is v1.2, v1.3 was standardized less than 2 Abuses of the missing integrity check have been exploited in practical years ago, v1.1 e v1.0 are expected to be deprecated by 2020 attacks (e.g. BEAST), leading to a strong recommendation of TLS fino alla versione 1.2 consente il downgrade trasparente della authenticated encryption modes connessione a SSLv3 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 3 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 4 / 32 TLS (SSL) - Basics and Standards Practical key sizes Ciphersuites Summary and recommendations The set of primitives employed by TLS is known as ciphersuite The computational security margin of the primitives of the ciphersuite It is expressed as TLS A WITH B C, where A,B,C are: should match Asymm. cipher, used in authentication (e.g. ) during key exch. A RSA The following table was provided by the Coordination & Support Default kex performed via RSA, Diffie-Hellman (DH RSA) and EC-based Diffie-Hellman (ECDH RSA) available Action ECRYPT in 2018, relying on a report by ENISA, is available at Authentication can be skipped specifying DH anon to have an www.keylength.com unauthenticated Diffie-Hellman based kex B Symm. cipher + mode of operation , used in data encryption, (e.g., Sec. Secret key/private key/digest size [b] AES GCM, 3DES2 CBC,RC4,Salsa20) Margin RSA ECDSA DSA AES Hash No padding strategy for block ciphers (random padding allowed) (key/group) NULL can be specified to employ TLS for endpoint auth. only Legacy 1024 160 160/1024 80 160 C Hash function, for MAC/signing (e.g. SHA256, SHA ! SHA-1) 10 years 3072 256 256/3072 128 256 The TLS standard advises against MD2,MD4,MD5 only after v1.1 30+ years 15360 512 512/15360 256 512 Example of a ciphersuite : TLS DHE RSA WITH AES 256 CBC SHA256 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 5 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 6 / 32 TLS v1.2 TLS (SSL) - Server only authentication Client Server Single sided authentication 1 [cli ! srv] ClientHello message w/ highest TLS version supported and the supported cipher suites in clear 2 [srv ! cli] ServerHello message w/ the protocol version and ciphersuite SYN TCP TLS choice, and a session random number (nonce) in clear SYN/ACK ACK 3 [srv ! cli] X.509 Certificate, and a ServerHelloDone message ClientHello ServerHello 4 Certificate [cli,local] Checks the certificate, [cli ! srv] ClientKeyExchange message ClientKeyExchange ServerHelloDone with premasterkey enciphered with the server's public key ChangeCipherSpec Finished ChangeCipherSpec 5 [srv and cli,local] Compute session key from nonces and premasterkey Finished Application 6 [ ! ] ChangeCipherSpec message, notifying that the Data cli srv Application communication will be encrypted and Finished message, containing a MAC Data of all the previous messages 7 [srv,local] decrypts the Finished message and [srv ! cli] an identical one G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 7 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 8 / 32 TLS (SSL) - Mutual authentication TLS (SSL) - Issues and Solutions Mutual Authentication Common Issues In the previous scheme, only the client authenticates the server Issue: Public key based key exchange is expensive, especially if identity: TLS supports also mutually authenticated communications there are many sessions in a short amount of time The mutual authentication is achieved through the client sending his Solution: fast session resume: the two endpoints exchange only the Hello messages, with the random nonce of the session they want to own certificate before the ClientKeyExchange message resume and switch to encrypted mode. After sending the ClientKeyExchange message, the client sends a The authentication between the parties is implicitly handled by the fact CertificateVerify message, which is a signature over all the previous that they both know the same session secret messages, allowing the server to check that the one who initiated the Issue: Long term private key leak implies that all the previous communication was effectively the client communications can be decrypted: no forward secrecy In this case, both the server and the client can close the connection if Solution: Enclose the secret session key in a Diffie-Hellman key the identity of the other is not the correct one preventing exchange protocol, allowing the DH parameters to be renewed by the impersonation attacks server. This is known as Ephemeral Diffie-Hellman (DHE). G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 9 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 10 / 32 TLS - Uses TLS - Common pitfalls De Facto standards Issues and mitigation HTTPS: HTTPS is basically plain HTTP traffic carried by an Weak ciphersuites open up to attacks: Don't use DES (small key) , SSL/TLS transport layer RC2 (small key), RC4 (broken in 2013 in the TLS use scenario) Secure SMTP/IMAP/POP3: all these protocols can (and should) be An attacker may force a downgrade of the ciphersuite altering the used with an TLS transport layer ClientHello message: Remove from accepted ciphersuites the vulnerable ones altogether OpenVPN: OpenVPN exploits TLS (instead of IpSEC or PPTP) as the transport protocol for point-to-point VPNs Cipher renegotiation allows an attacker to splice a request into a TLS setup: a fix is standardized in RFC5746 and implemented in Handling legacy application level protocols recent OpenSSL/GNUTLS/NSS The Heartbleed bug: affecting OpenSSL, it is not a TLS weakness, TLS is designed to provide confidentiality and endpoint it's simply a CS-101 programming error (missing check on the size of authentication for any TCP based communication. a memcpy): get a fixed implementation stunnel: The Stunnel utility provides a TLS transport wrapper for When possible, use an authenticated mode of operation (e.g., GCM) any protocol you like acting as a portmapper and TLS v1.2 to fix padding-based attacks (e.g. BEAST) G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 11 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 12 / 32 TLS 1.3 SSH - Basics Novit`arispetto alla versione precedente Overview Cut down by 1 RTT the setup latency: client sends session key share The Secure SHell Protocol suite was designed at first (1995) to and supported ciphers with ClientHello protect remote login/shell applications from eavesdropping (i.e. Added features: provide confidentiality) Perfect forward secrecy providing key exchange now mandatory In the years it has grown to a full fledged protocol suite ChaCha20 (tweakable block cipher), Poly1305 (MAC), ED25519 (DSA) (encompassing 15 RFC) with separated layers for authentication, Removed Features (bugs?): transport and multiple connection handling Transparent downgrading to previous versions: TLS v.1.3 server writes DOWNGRD in the first characters of nonce if downgrading to v1.2 Most popular implementations (OpenSSH and Putty) support Weak primitives: (e.g., MD5, SHA-1, SHA-2-224, DES, RC4, custom advanced features such as providing a forwarding tunnel for a TCP DH groups) connection flow and a dedicated file transfer protocol (SFTP) Export-grade ciphers (e.g., RSA-512) SSH uses a hybrid (asymmetric+symmetric) encryption scheme Data compression (may leak information) and ciphersuite renegotiation similar to TLS, while allowing different methods for authentication (in-flight downgrades were possible) G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 13 / 32 G. Pelosi, A. Barenghi (DEI) Secure Transport Protocols 14 / 32 SSH - Session authentication SSH - Session authentication User Authentication Protocol
Load more

Recommended publications
  • Libressl Presentatie2
    Birth of LibreSSL and its current status Frank Timmers Consutant, Snow B.V. Background What is LibreSSL • A fork of OpenSSL 1.0.1g • Being worked on extensively by a number of OpenBSD developers What is OpenSSL • OpenSSL is an open source SSL/TLS crypto library • Currently the de facto standard for many servers and clients • Used for securing http, smtp, imap and many others Alternatives • Netscape Security Services (NSS) • BoringSSL • GnuTLS What is Heartbleed • Heartbleed was a bug leaking of private data (keys) from both client and server • At this moment known as “the worst bug ever” • Heartbeat code for DTLS over UDP • So why was this also included in the TCP code? • Not the reason to create a fork Why did this happen • Nobody looked • Or at least didn’t admit they looked Why did nobody look • The code is horrible • Those who did look, quickly looked away and hoped upstream could deal with it Why was the code so horrible • Buggy re-implementations of standard libc functions like random() and malloc() • Forces all platforms to use these buggy implementations • Nested #ifdef, #ifndefs (up to 17 layers deep) through out the code • Written in “OpenSSL C”, basically their own dialect • Everything on by default Why was it so horrible? crypto_malloc • Never frees memory (Tools like Valgrind, Coverity can’t spot bugs) • Used LIFO recycling (Use after free?) • Included debug malloc by default, logging private data • Included the ability to replace malloc/free at runtime #ifdef trees • #ifdef, #elif, #else trees up to 17 layers deep • Throughout the complete source • Some of which could never be reached • Hard to see what is or not compiled in 1.
    [Show full text]
  • Not-Quite-So-Broken TLS Lessons in Re-Engineering a Security Protocol Specification and Implementation
    Not-quite-so-broken TLS Lessons in re-engineering a security protocol specification and implementation David Kaloper Meršinjak Hannes Mehnert Peter Sewell Anil Madhavapeddy University of Cambridge, Computer Labs Usenix Security, Washington DC, 12 August 2015 INT SSL23_GET_CLIENT_HELLO(SSL *S) { CHAR BUF_SPACE[11]; /* REQUEST THIS MANY BYTES IN INITIAL READ. * WE CAN DETECT SSL 3.0/TLS 1.0 CLIENT HELLOS * ('TYPE == 3') CORRECTLY ONLY WHEN THE FOLLOWING * IS IN A SINGLE RECORD, WHICH IS NOT GUARANTEED BY * THE PROTOCOL SPECIFICATION: * BYTE CONTENT * 0 TYPE \ * 1/2 VERSION > RECORD HEADER * 3/4 LENGTH / * 5 MSG_TYPE \ * 6-8 LENGTH > CLIENT HELLO MESSAGE Common CVE sources in 2014 Class # Memory safety 15 State-machine errors 10 Certificate validation 5 ASN.1 parsing 3 (OpenSSL, GnuTLS, SecureTransport, Secure Channel, NSS, JSSE) Root causes Error-prone languages Lack of separation Ambiguous and untestable specification nqsb approach Choice of language and idioms Separation and modular structure A precise and testable specification of TLS Reuse between specification and implementation Choice of language and idioms OCaml: a memory-safe language with expressive static type system Well contained side-effects Explicit flows of data Value-based Explicit error handling We leverage it for abstraction and automated resource management. Formal approaches Either reason about a simplified model of the protocol; or reason about small parts of OpenSSL. In contrast, we are engineering a deployable implementation. nqsb-tls A TLS stack, developed from scratch, with dual goals: Executable specification Usable TLS implementation Structure nqsb-TLS ML module layout Core Is purely functional: VAL HANDLE_TLS : STATE -> BUFFER -> [ `OK OF STATE * BUFFER OPTION * BUFFER OPTION | `FAIL OF FAILURE ] Core OCaml helps to enforce state-machine invariants.
    [Show full text]
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019
    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
    [Show full text]
  • Black-Box Security Analysis of State Machine Implementations Joeri De Ruiter
    Black-box security analysis of state machine implementations Joeri de Ruiter 18-03-2019 Agenda 1. Why are state machines interesting? 2. How do we know that the state machine is implemented correctly? 3. What can go wrong if the implementation is incorrect? What are state machines? • Almost every protocol includes some kind of state • State machine is a model of the different states and the transitions between them • When receiving a messages, given the current state: • Decide what action to perform • Which message to respond with • Which state to go the next Why are state machines interesting? • State machines play a very important role in security protocols • For example: • Is the user authenticated? • Did we agree on keys? And if so, which keys? • Are we encrypting our traffic? • Every implementation of a protocol has to include the corresponding state machine • Mistakes can lead to serious security issues! State machine example Confirm transaction Verify PIN 0000 Failed Init Failed Verify PIN 1234 OK Verified Confirm transaction OK State machines in specifications • Often specifications do not explicitly contain a state machine • Mainly explained in lots of prose • Focus usually on happy flow • What to do if protocol flow deviates from this? Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
    [Show full text]
  • Vetting SSL Usage in Applications with SSLINT
    2015 IEEE Symposium on Security and Privacy Vetting SSL Usage in Applications with SSLINT Boyuan He1, Vaibhav Rastogi2, Yinzhi Cao3, Yan Chen2, V.N. Venkatakrishnan4, Runqing Yang1, and Zhenrui Zhang1 1Zhejiang University 2Northwestern University 3Columbia University 4University of Illinois, Chicago [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] Abstract—Secure Sockets Layer (SSL) and Transport Layer In particular, we ask the following research question: Is it Security (TLS) protocols have become the security backbone of possible to design scalable techniques that detect incorrect use the Web and Internet today. Many systems including mobile of APIs in applications using SSL/TLS libraries? This question and desktop applications are protected by SSL/TLS protocols against network attacks. However, many vulnerabilities caused poses the following challenges: by incorrect use of SSL/TLS APIs have been uncovered in recent • Defining and representing correct use. Given an SSL years. Such vulnerabilities, many of which are caused due to poor library, how do we model correct use of the API to API design and inexperience of application developers, often lead to confidential data leakage or man-in-the-middle attacks. In this facilitate detection? paper, to guarantee code quality and logic correctness of SSL/TLS • Analysis techniques for incorrect usage in software. applications, we design and implement SSLINT, a scalable, Given a representation of correct usage, how do we de- automated, static analysis system for detecting incorrect use sign techniques for analyzing programs to detect incorrect of SSL/TLS APIs.
    [Show full text]
  • You Really Shouldn't Roll Your Own Crypto: an Empirical Study of Vulnerabilities in Cryptographic Libraries
    You Really Shouldn’t Roll Your Own Crypto: An Empirical Study of Vulnerabilities in Cryptographic Libraries Jenny Blessing Michael A. Specter Daniel J. Weitzner MIT MIT MIT Abstract A common aphorism in applied cryptography is that cryp- The security of the Internet rests on a small number of open- tographic code is inherently difficult to secure due to its com- source cryptographic libraries: a vulnerability in any one of plexity; that one should not “roll your own crypto.” In par- them threatens to compromise a significant percentage of web ticular, the maxim that complexity is the enemy of security traffic. Despite this potential for security impact, the character- is a common refrain within the security community. Since istics and causes of vulnerabilities in cryptographic software the phrase was first popularized in 1999 [52], it has been in- are not well understood. In this work, we conduct the first voked in general discussions about software security [32] and comprehensive analysis of cryptographic libraries and the vul- cited repeatedly as part of the encryption debate [26]. Conven- nerabilities affecting them. We collect data from the National tional wisdom holds that the greater the number of features Vulnerability Database, individual project repositories and in a system, the greater the risk that these features and their mailing lists, and other relevant sources for eight widely used interactions with other components contain vulnerabilities. cryptographic libraries. Unfortunately, the security community lacks empirical ev- Among our most interesting findings is that only 27.2% of idence supporting the “complexity is the enemy of security” vulnerabilities in cryptographic libraries are cryptographic argument with respect to cryptographic software.
    [Show full text]
  • Xerox® Igen™ 150 Press 3 Party Software License Disclosure
    Xerox® iGen™ 150 Press 3rd Party Software License Disclosure October 2013 The following software packages are copyrighted for use in this product according to the license stated. Full terms and conditions of all 3rd party software licenses are available from the About screen under the Help menu on the Press Interface or by accessing the Support & Drivers page located on the http://www.xerox.com website. Adobe Icons and Web Logos, license: Adobe Icons and Web Logos License Apache log4j 1.2.8, Apache log4j 1.2.9, Apache Web Services XML-RPC 1.2.b1, Apache Lucene Java 1.3, Apache Tomcat 4.1.27, license: Apache License 1.1 Apache Axis 1.x 1.4, Apache Jakarta Commons HttpClient 3.0.alpha1, Apache Jakarta Commons Logging 1.0.4, Apache Jakarta Lucene 1.9.1, Apache XML Security Java 1.3.0, saxpath 1.0 FCS, Skin Look And Feel (skinlf) 1.2.8, Spring Framework Utilities 0.7, Apache Web Services Axis 1.2rc3, Apache Xerces Java XML Parser 2.7.1, Apache XML Xalan-Java 2.7.0, Jetty - Java HTTP Servlet Server 4.0.D0, Lucene Snowball, Streaming API for XML (StAX) - JSR-173 20040819, license: Apache License 2.0 Perl 5.8.5, Perl 5.10.0, AppConfig-1.66, Archive-Tar-1.58, Compress::Zlib-2.020, Expect.pm- 1.21, File-NCopy-0.36, File-NFSLock-1.20, Filesys-Df-0.92, Filesys-DiskFree-0.06, HTML- Parser-3.69, HTML-Tagset-3.20, HTML-Template-2.9, IO-Stty-0.02, IO-Tty-1.08, IO-Zlib- 1.09, libxml-perl-0.08, Net-Netmask-1.9015, Net-Telnet-3.03, perl-5.8.3, perlindex-1.605, Pod- Escapes-1.04, Pod-POM-0.25, Pod-Simple-3.13, Proc-ProcessTable-0.45, Socket6-0.23, Stat-
    [Show full text]
  • Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation
    Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation David Kaloper-Meršinjak, Hannes Mehnert, Anil Madhavapeddy, and Peter Sewell, University of Cambridge https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kaloper-mersinjak This paper is included in the Proceedings of the 24th USENIX Security Symposium August 12–14, 2015 • Washington, D.C. ISBN 978-1-939133-11-3 Open access to the Proceedings of the 24th USENIX Security Symposium is sponsored by USENIX Not-quite-so-broken TLS: lessons in re-engineering a security protocol specification and implementation David Kaloper-Mersinjakˇ †, Hannes Mehnert†, Anil Madhavapeddy and Peter Sewell University of Cambridge Computer Laboratory [email protected] † These authors contributed equally to this work Abstract sensitive services, they are not providing the security we need. Transport Layer Security (TLS) is the most widely Transport Layer Security (TLS) implementations have a deployed security protocol on the Internet, used for au- history of security flaws. The immediate causes of these thentication and confidentiality, but a long history of ex- are often programming errors, e.g. in memory manage- ploits shows that its implementations have failed to guar- ment, but the root causes are more fundamental: the chal- antee either property. Analysis of these exploits typically lenges of interpreting the ambiguous prose specification, focusses on their immediate causes, e.g. errors in mem- the complexities inherent in large APIs and code bases, ory management or control flow, but we believe their root inherently unsafe programming choices, and the impos- causes are more fundamental: sibility of directly testing conformance between imple- mentations and the specification.
    [Show full text]
  • Cloudtransport: Using Cloud Storage for Censorship-Resistant Networking
    CloudTransport: Using Cloud Storage for Censorship-Resistant Networking Chad Brubaker1,2, Amir Houmansadr2, and Vitaly Shmatikov2 1 Google 2 The University of Texas at Austin Abstract. Censorship circumvention systems such as Tor are highly vulnerable to network-level filtering. Because the traffic generated by these systems is disjoint from normal network traffic, it is easy to recog- nize and block, and once the censors identify network servers (e.g., Tor bridges) assisting in circumvention, they can locate all of their users. CloudTransport is a new censorship-resistant communication system that hides users’ network traffic by tunneling it through a cloud storage ser- vice such as Amazon S3. The goal of CloudTransport is to increase the censors’ economic and social costs by forcing them to use more expen- sive forms of network filtering, such as large-scale traffic analysis, or else risk disrupting normal cloud-based services and thus causing collateral damage even to the users who are not engaging in circumvention. Cloud- Transport’s novel passive-rendezvous protocol ensures that there are no direct connections between a CloudTransport client and a CloudTrans- port bridge. Therefore, even if the censors identify a CloudTransport connection or the IP address of a CloudTransport bridge, this does not help them block the bridge or identify other connections. CloudTransport can be used as a standalone service, a gateway to an anonymity network like Tor, or a pluggable transport for Tor. It does not require any modifications to the existing cloud storage, is compatible with multiple cloud providers, and hides the user’s Internet destinations even if the provider is compromised.
    [Show full text]
  • Reliable Logging Enhancements in Red Hat Enterprise Linux 6
    Reliable Logging Enhancements in Red Hat Enterprise Linux 6 Rich Jerrido - RHCA, RHCVA – Solutions Architect Logging, why should you care? ● Troubleshooting ● Compliance (PCI, SOX, HIPPA, etc) ● Security ● Auditing ● Because my Red Hat Solutions Architect ™ said so 2 Red Hat Enterprise Linux 6 Rsyslog ● Introduced as optional drop-in replacement for sysklogd in RHEL5.2 ● Default syslog daemon in RHEL6 (version 4.x) ● Designed to be a modern replacement to sysklogd adding features & capabilities 3 Red Hat Enterprise Linux 6 Rsyslog Features ● Rsyslog Features ● Multi-threaded syslog daemon ● TCP, SSL, TLS, RELP ● MySQL, PostgreSQL ● ISO 8601 timestamp support (millisecond granularity and timezone information) ● On-disk queuing ● Componentized design (load only the modules you need) ● Filter any part of syslog message ● Fully configurable output format 4 Red Hat Enterprise Linux 6 RELP ● Reliable Event Logging Protocol ● Not just for syslog ● Similar in purpose to AMQP (Advanced Message Queuing Protocol) - line-level protocol ● Designed to address deficiencies of TCP, mainly that TCP provides reliability at the connection level. RELP provides reliability at the application level. RELP usage implies TCP usage. ● Provided via the rsyslog-relp package. 5 Red Hat Enterprise Linux 6 Security ● GNUTLS ● Provided via the rsyslog-gnutls package ● Provides SSL ● Currently mutually-exclusive with RELP ● Stunnel ● Provides SSL layer encryption of syslog traffic ● Use with rsyslog-relp for best effect (secure + reliable) ● Provides a slew of other features
    [Show full text]
  • A Technical Comparison of Ipsec and SSL
    A Technical Comparison of IPSec and SSL y Ab delNasir Alshamsi Takamichi Saito Tokyo University of Technology Abstract p osed but the most famous secure and widely de ployed are IPSec IP Security and SSL Secure So cket Layer IPSec IP Security and SSL SecureSocket Layer In this pap er we will provide a technical comparison have been the most robust and most potential tools of IPSec and SSL the similarities and the dierences available for securing communications over the Inter of the cryptographic prop erties The results of per net Both IPSec and SSL have advantages and short formance are based on comparing FreeSWAN as comings Yet no paper has been found comparing the IPSec and Stunnel as SSL two protocols in terms of characteristic and functional ity Our objective is to present an analysis of security and performancepr operties for IPSec and SSL IPSec IPSec is an IP layer proto col that enables the Intro duction sending and receiving of cryptographically protected packets of any kind TCPUDPICMPetc without any provides two kinds of crypto mo dication IPSec Securing data over the network is hard and compli graphic services Based on necessity IPSec can provide cated issue while the threat of data mo dication and condentiality and authenticity or it can provide data interruption is rising The goal of network security authenticity only is to provide condentiality integrity and authenticity Condentiality is keeping the data secret from the ESP Encapsulated SecurityPayload unintended listeners on the network Integrity is en suring
    [Show full text]
  • Analysis of DTLS Implementations Using Protocol State Fuzzing
    Analysis of DTLS Implementations Using Protocol State Fuzzing Paul Fiterau-Brostean and Bengt Jonsson, Uppsala University; Robert Merget, Ruhr-University Bochum; Joeri de Ruiter, SIDN Labs; Konstantinos Sagonas, Uppsala University; Juraj Somorovsky, Paderborn University https://www.usenix.org/conference/usenixsecurity20/presentation/fiterau-brostean This paper is included in the Proceedings of the 29th USENIX Security Symposium. August 12–14, 2020 978-1-939133-17-5 Open access to the Proceedings of the 29th USENIX Security Symposium is sponsored by USENIX. Analysis of DTLS Implementations Using Protocol State Fuzzing Paul Fiterau-Bro¸stean˘ Bengt Jonsson Robert Merget Joeri de Ruiter Uppsala University Uppsala University Ruhr University Bochum SIDN Labs Konstantinos Sagonas Juraj Somorovsky Uppsala University Paderborn University Abstract reach 11.6 billion by 2021 [26]. This will constitute half of all devices connected to the Internet, with the percentage set to Recent years have witnessed an increasing number of proto- grow in subsequent years. Such trends also increase the need cols relying on UDP. Compared to TCP, UDP offers perfor- to ensure that software designed for these devices is properly mance advantages such as simplicity and lower latency. This scrutinized, particularly with regards to its security. has motivated its adoption in Voice over IP, tunneling techno- DTLS is also used as one of the two security protocols in logies, IoT, and novel Web protocols. To protect sensitive data WebRTC, a framework enabling real-time communication. exchange in these scenarios, the DTLS protocol has been de- WebRTC can be used, for example, to implement video con- veloped as a cryptographic variation of TLS.
    [Show full text]