Scribd Logo
Upload

Welcome to Scribd!

  • 35 views

    10SSL

    Uploaded by

    Ryan Pahrun
    This document summarizes the SSL/TLS protocol. It discusses how public keys are authenticated using certificates signed by a certificate authority (CA). It describes how hierarchical CAs and certificate chains work. It also covers alternative approaches like PGP's web of trust. The document analyzes attacks on early key exchange protocols and how SSL addresses them by having the client sign a random value sent by the server. It provides an overview of the TLS handshake protocol and the messages exchanged. In particular, it explains how the client and server negotiate a cipher suite and establish a shared secret to protect subsequent communication.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    10SSL

    Uploaded by

    Ryan Pahrun
    35 views18 pages
    This document summarizes the SSL/TLS protocol. It discusses how public keys are authenticated using certificates signed by a certificate authority (CA). It describes how hierarchical CAs and certificate chains work. It also covers alternative approaches like PGP's web of trust. The document analyzes attacks on early key exchange protocols and how SSL addresses them by having the client sign a random value sent by the server. It provides an overview of the TLS handshake protocol and the messages exchanged. In particular, it explains how the client and server negotiate a cipher suite and establish a shared secret to protect subsequent communication.

    Original Description:

    ss

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document summarizes the SSL/TLS protocol. It discusses how public keys are authenticated using certificates signed by a certificate authority (CA). It describes how hierarchical CAs and certificate chains work. It also covers alternative approaches like PGP's web of trust. The document analyzes attacks on early key exchange protocols and how SSL addresses them by having the client sign a random value sent by the server. It provides an overview of the TLS handshake protocol and the messages exchanged. In particular, it explains how the client and server negotiate a cipher suite and establish a shared secret to protect subsequent communication.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    35 views18 pages

    10SSL

    Uploaded by

    Ryan Pahrun
    This document summarizes the SSL/TLS protocol. It discusses how public keys are authenticated using certificates signed by a certificate authority (CA). It describes how hierarchical CAs and certificate chains work. It also covers alternative approaches like PGP's web of trust. The document analyzes attacks on early key exchange protocols and how SSL addresses them by having the client sign a random value sent by the server. It provides an overview of the TLS handshake protocol and the messages exchanged. In particular, it explains how the client and server negotiate a cipher suite and establish a shared secret to protect subsequent communication.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 18

    SSL/TLS

    EJ Jung
    10/18/10

    Authenticity of Public Keys


    Bo
    bs

    ke
    y

    ?
    private key

    Alice

    Bob
    public key

    Problem: How does Alice know that the public key


    she received is really Bobs public key?

    Distribution of Public Keys


    ! Public announcement or public directory
    Risks: forgery and tampering

    ! Public-key certificate
    Signed statement specifying the key and identity
    sigAlice(Bob, PKB)

    ! Common approach: certificate authority (CA)


    Single agency responsible for certifying public keys
    After generating a private/public key pair, user proves
    his identity and knowledge of the private key to obtain
    CAs certificate for the public key (offline)
    Every computer is pre-configured with CAs public key

    Using Public-Key Certificates

    Authenticity of public keys is reduced to


    authenticity of one key (CAs public key)

    Hierarchical Approach
    ! Single CA certifying every public key is impractical
    ! Instead, use a trusted root authority
    For example, Verisign
    Everybody must know the public key for verifying root
    authoritys signatures

    ! Root authority signs certificates for lower-level


    authorities, lower-level authorities sign certificates
    for individual networks, and so on
    Instead of a single certificate, use a certificate chain
    sigVerisign(UI, PKUI), sigUI(EJ Jung, PKE)

    What happens if root authority is ever compromised?

    Alternative: Web of Trust


    ! Used in PGP (Pretty Good Privacy)
    ! Instead of a single root certificate authority, each
    person has a set of keys they trust
    If public-key certificate is signed by one of the trusted
    keys, the public key contained in it will be deemed valid

    ! Trust can be transitive


    Can use certified keys for further certification

    I trust
    Alice

    sigAlice(Friend, Friends key)


    sigFriend(FoaF, FoaFs key)

    Alice

    Friend of Alice

    Friend of friend

    Bob

    X.509 Authentication Service


    ! ITU-T standard
    ! Specifies certificate format
    X.509 certificates are used in IPSec and SSL/TLS

    ! Specifies certificate directory service


    For retrieving other users CA-certified public keys

    ! Specifies a set of authentication protocols


    For proving identity using public-key signatures

    ! Does not specify crypto algorithms


    Can use it with any digital signature scheme and hash
    function, but hashing is required before signing

    X.509 Version 1
    Alice, sigAlice(TimeAlice, Bob,
    encryptPublicKey(Bob)(message))
    Alice

    Bob

    ! Encrypt, then sign for authenticated encryption


    Goal: achieve both confidentiality and authentication
    E.g., encrypted, signed password for access control

    ! Does this work?

    Attack on X.509 Version 1


    Attacker extracts encrypted
    password and replays it
    under his own signature
    Alice, sigAlice(TimeAlice, Bob,
    encryptPublicKey(Bob)(password))

    Alice

    Bob
    Charlie, sigCharlie(TimeCharlie, Bob,
    encryptPublicKey(Bob)(password))

    ! Receiving encrypted password under signature does not


    mean that the sender actually knows the password!
    ! Proper usage: sign, then encrypt

    Denning-Sacco Protocol
    Certificate server
    Alice, Bob
    certAlice, certBob
    Im Alice, certAlice, certBob,
    encryptPublicKey(Bob)(sigAlice(TimeAlice, KAB))
    Alice

    Bob

    ! Goal: establish a new shared key KAB with the


    help of a trusted certificate service

    Attack on Denning-Sacco
    Nothing in this
    signature says that it
    was sent to Bob!
    Im Alice, certAlice, certBob,
    encryptPublicKey(Bob)(sigAlice(TimeAlice, KAC))

    Im Alice, certAlice,
    certCharlie,
    encryptPublicKey(Charlie)(
    sigAlice(TimeAlice, KAC))

    Alice

    Charlie

    Bob

    (with an evil side)

    ! Alices signature is insufficiently explicit


    Does not say to whom and why it was sent

    ! Alices signature can be used to impersonate her

    Authentication with Public Keys


    PRIVATE
    KEY

    PUBLIC
    KEY

    I am Alice
    fresh random challenge C
    Alice

    sigAlice(C)

    Bob

    Verify Alices signature on c

    !" Only Alice can create a valid signature


    #" Signature is on a fresh, unpredictable challenge
    Potential problem: Alice will sign anything

    Mafia-in-the-Middle Attack
    PRIVATE
    KEY K

    Picture 143!
    Prove your age
    by signing X
    sigK(x)

    customer

    XXX

    Adult
    entertainment
    Over 21 only!

    [from Andersons book]

    Buy 10
    gold coins
    Sign X

    sigK(x)

    Bank

    Mafia porn site

    Early Version of SSL (Simplified)


    fresh session key

    encryptPublicKey(Bob)(Alice, KAB)
    fresh random number

    encryptKAB(NB)
    Alice

    encryptKAB(Alice, sigAlice(NB))

    Bob

    ! Bobs reasoning: I must be talking to Alice because


    Whoever signed NB knows Alices private key Only Alice knows
    her private key Alice must have signed NB NB is fresh and
    random and I sent it encrypted under KAB Alice could have
    learned NB only if she knows KAB She must be the person who
    sent me KAB in the first message...

    Breaking Early SSL


    encryptPK(Charlie)(Alice,KAC)

    encryptPK(Bob)(Alice,KCB)
    encryptKCB(NB)

    encryptKAC(NB)

    Alice

    encKAC(Alice, sigAlice(NB))

    Charlie

    encryptKCB(Alice, sigAlice(NB))

    Bob

    (with an evil side)

    ! Charlie uses his legitimate conversation with Alice


    to impersonate Alice to Bob
    Information signed by Alice is not sufficiently explicit

    What is SSL / TLS?


    ! Transport Layer Security protocol, version 1.0
    De facto standard for Internet security
    The primary goal of the TLS protocol is to provide
    privacy and data integrity between two communicating
    applications
    In practice, used to protect information transmitted
    between browsers and Web servers

    ! Based on Secure Sockets Layers protocol, ver 3.0


    Same protocol design, different algorithms

    ! Deployed in nearly every Web browser


    slide 17

    SSL / TLS in the Real World

    slide 18

    Application-Level Protection
    application

    email, Web, NFS

    presentation
    session
    transport
    network
    data link

    RPC
    TCP

    Protects againt application-level threats


    (e.g.,server impersonation), NOT
    against IP-level threats (spoofing, SYN
    flood, DDoS by data flood)

    IP
    802.11

    physical

    slide 19

    History of the Protocol


    ! SSL 1.0
    Internal Netscape design, early 1994?
    Lost in the mists of time

    ! SSL 2.0
    Published by Netscape, November 1994
    Several weaknesses

    ! SSL 3.0
    Designed by Netscape and Paul Kocher, November 1996

    ! TLS 1.0
    Internet standard based on SSL 3.0, January 1999
    Not interoperable with SSL 3.0
    TLS uses HMAC instead of MAC; can run on any port

    slide 20

    Request for Comments


    ! Network protocols are usually disseminated in the
    form of an RFC
    ! TLS version 1.0 is described in RFC 2246
    ! Intended to be a self-contained definition of the
    protocol
    Describes the protocol in sufficient detail for readers
    who will be implementing it and those who will be
    doing protocol analysis
    Mixture of informal prose and pseudo-code

    slide 21

    Evolution of the SSL/TLS RFC

    slide 22

    TLS Basics
    ! TLS consists of two protocols
    Familiar pattern for key exchange protocols

    ! Handshake protocol
    Use public-key cryptography to establish a shared
    secret key between the client and the server

    ! Record protocol
    Use the secret key established in the handshake
    protocol to protect communication between the client
    and the server

    ! We will focus on the handshake protocol


    slide 23

    TLS Handshake Protocol


    ! Two parties: client and server
    ! Negotiate version of the protocol and the set of
    cryptographic algorithms to be used
    Interoperability between different implementations of
    the protocol

    ! Authenticate client and server (optional)


    Use digital certificates to learn each others public keys
    and verify each others identity

    ! Use public keys to establish a shared secret


    slide 24

    Handshake Protocol Structure


    ClientHello
    ServerHello,
    [Certificate],
    [ServerKeyExchange],
    [CertificateRequest],
    ServerHelloDone

    [Certificate],
    ClientKeyExchange,
    [CertificateVerify]
    switch to negotiated cipher
    Finished

    Record of all sent and


    received handshake messages

    switch to negotiated cipher


    Finished
    slide 25

    ClientHello
    ClientHello

    Client announces (in plaintext):


    Protocol version he is running
    Cryptographic algorithms he supports

    slide 26

    ClientHello (RFC)
    Highest version of the protocol
    struct {
    supported by the client
    ProtocolVersion client_version;
    Session id (if the client wants to
    Random random;
    resume an old session)
    SessionID session_id;
    Set of cryptographic algorithms
    supported by the client (e.g.,
    CipherSuite cipher_suites;
    RSA or Diffie-Hellman)
    CompressionMethod compression_methods;
    } ClientHello

    slide 27

    ServerHello
    C, Versionc, suitec, Nc
    ServerHello

    Server responds (in plaintext) with:


    Highest protocol version supported by
    both client and server
    Strongest cryptographic suite selected
    from those offered by the client

    slide 28

    ServerKeyExchange
    C, Versionc, suitec, Nc
    Versions, suites, Ns,
    ServerKeyExchange

    Server sends his public-key certificate


    containing either his RSA, or
    his Diffie-Hellman public key
    (depending on chosen crypto suite)

    slide 29

    ClientKeyExchange
    C, Versionc, suitec, Nc
    Versions, suites, Ns,
    sigca(S,Ks),
    ServerHelloDone

    ClientKeyExchange

    Client generates some secret key material


    and sends it to the server encrypted with
    the servers public key (if using RSA)

    slide 30

    ClientKeyExchange (RFC)
    struct {
    select (KeyExchangeAlgorithm) {
    case rsa: EncryptedPreMasterSecret;
    case diffie_hellman: ClientDiffieHellmanPublic;
    } exchange_keys
    } ClientKeyExchange
    struct {
    ProtocolVersion client_version;
    Random bits from which
    opaque random[46];
    symmetric keys will be derived
    (by hashing them with nonces)
    } PreMasterSecret

    slide 31

    Core SSL 3.0 Handshake


    C, Versionc=3.0, suitec, Nc
    Versions=3.0, suites, Ns,
    sigca(S,Ks),
    ServerHelloDone

    {Secretc}Ks
    If the protocol is correct, C and S share
    some secret key material (secretc) at this point
    switch to key derived
    from secretc, Nc, Ns

    switch to key derived


    from secretc, Nc, Ns
    slide 32

    Version Rollback Attack


    C, Versionc=2.0, suitec, Nc

    Server is fooled into thinking he


    is communicating with a client
    who supports only SSL 2.0

    Versions=2.0, suites, Ns,


    sigca(S,Ks),
    ServerHelloDone

    {Secretc}Ks

    C and S end up communicating using SSL 2.0


    (weaker earlier version of the protocol that
    does not include Finished messages)
    slide 33

    SSL 2.0 Weaknesses (Fixed in 3.0)


    ! Cipher suite preferences are not authenticated
    Cipher suite rollback attack is possible

    ! Weak MAC construction


    ! SSL 2.0 uses padding when computing MAC in
    block cipher modes, but padding length field is
    not authenticated
    Attacker can delete bytes from the end of messages

    ! MAC hash uses only 40 bits in export mode


    ! No support for certificate chains or non-RSA
    algorithms, no handshake while session is open
    slide 34

    Chosen-Protocol Attacks
    ! Why do people release new versions of security
    protocols? Because the old version got broken!
    ! New version must be backward-compatible
    Not everybody upgrades right away

    ! Attacker can fool someone into using the old,


    broken version and exploit known vulnerability
    Similar: fool victim into using weak crypto algorithms

    ! Defense is hard: must authenticate version early


    ! Many protocols had version rollback attacks
    SSL, SSH, GSM (cell phones)
    slide 35

    Version Check in SSL 3.0


    C, Versionc=3.0, suitec, Nc

    Versions=3.0, suites, Ns,


    sigca(S,Ks),
    ServerHelloDone

    Embed version
    number into secret

    {Versionc,Secretc}Ks

    Check that received version is equal to


    the version in ClientHello

    If the protocol is correct, C and S share


    some secret key material secretc at this point

    switch to key derived


    from secretc, Nc, Ns

    switch to key derived


    from secretc, Nc, Ns
    slide 36

    SSL/TLS Record Protection

    Use symmetric keys


    established in handshake protocol

    slide 37

    You might also like

    pFad - Phonifier reborn

    Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

    Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


    Alternative Proxies:

    Alternative Proxy

    pFad Proxy

    pFad v3 Proxy

    pFad v4 Proxy