tls/ssl primer: protocols, x.509, pkcs, and tools€“ asymmetric and symmetric keys – rsa/dsa...

© Copyright 2000-2012 TIBCO Software Inc.

TLS/SSL PRIMER: PROTOCOLS, X.509, PKCS, AND TOOLS

TIBCO Software Inc.


Agenda

• Transport Level Security/Secure Sockets Layer (TLS and SSL)

– Not covering IPSec, SSH, or DTLS

• Finding the “Chain of Trust”

• Public Key Infrastructure and select Public-Key Cryptography Standards

– Basic Concepts: Identity, Integrity, Confidentiality

– Trust – Registration Authority/Certificate Authority

– Common Terms

– Asymmetric and Symmetric Keys – RSA/DSA Key Pairs – PKCS#12/X.509

– TLSv1 Handshake – Unilateral vs. Bilateral/Mutual Authentication

– Variations: IETF RFC quirks

– Revocation

• Flow of Using your own CA

• Common OpenSSL Routines

• Troubleshooting and Configuration

• Appendix: Brief History & Timelines


Finding the Chain-of-Trust

• Facts:

– PKCS#12 Stores are commonly used for Server SSL Identity

– PKCS#12 Stores may have a ‘chain’ of higher-up certificates (Same with

PKCS#7 „bags‟)

– There is no mandate to include a chain or even the full chain

– The use of a Browser often suffices to find the full chain

– Browsers seem to have agreed to use the CommonName of the Issuer to find

the Parent

– Browsers seem to have a flaw in finding the correct Parent if there are multiple

certificates with the same CN – they find the newest one, which may not be the

right one.

– OpenSSL/Portecle: “showcerts”

– You can chase Authority Key Identifier, but it isn‟t in all CA/Intermediate/Root

certificates

– Fool-proof is to use the CA‟s Public Key to validate the Server Certs signature.

– Fool-proof is to extract a full chain, if available, from a PKCS#12 that has it (as

shown earlier)


TLS/SSL is at the Transport Level

• Below HTTP, so you can point your browser at EMS or LDAP/s for

example

– Point my browser at my EMS instance: https://someone-wk.na.tibco.com:7243


Getting a Chain with a Browser

• View Certificate

• View Certificate Path

• Install Certificate


Chains

• Walk the Certificate Path

• View/Install/Note Details

– Especially Serial Number

• …then Export/Copy_to_File


Chains

• Export to File


Browser False Chains – tibco.tibbr.com

8

IE9 FF12 Ch 21


tibco.tibbr.com‟s True Chain

9

Certificate chain

0 s:/O=tibco.tibbr.com/OU=Domain Control Validated/CN=tibco.tibbr.com

i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go

Daddy Secure Certification Authority/serialNumber=07969287

1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go


i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority

2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority

i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation

Authority/CN=http://www.valicert.com//[email protected]

3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation




openssl s_client –connect tibco.tibbr.com:443 -showcerts


Finding the Chain-of-Trust - OpenSSL “showcerts”

C:\>openssl s_client -connect tibco.tibbr.com:443 –showcerts

Loading 'screen' into random state - done

CONNECTED(000001AC)

depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation


verify error:num=19:self signed certificate in certificate chain

verify return:0

---

Certificate chain

0 s:/O=tibco.tibbr.com/OU=Domain Control Validated/CN=tibco.tibbr.com

i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go


-----BEGIN CERTIFICATE-----

MIIFZzCCBE+gAwIBAgIHKxXiNIoMyjANBgkqhkiG9w0BAQUFADCByjELMAkGA1UE

BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAY

BgNVBAoTEUdvRGFkZHkuY29tLCBJbmMuMTMwMQYDVQQLEypodHRwOi8vY2VydGlm

[snip]

1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go


i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority

2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority



3 s:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation





Finding the Chain-of-Trust - Portecle

• Double-Click on portecle.jar

• File – Open CA Certs Keystore

• Examine - SSL/TLS Connection

• Supply Hostname or IP Addr & Port #


Chain with Portecle (con‟t)

1 of 3 Certificates

PEM Encoding


Portecle (con‟t)

• Three Certificates in Chain – keep saving them…

• #1 Subject: CN=www.paypal.com, OU=PayPal Production, O="PayPal, Inc.", STREET=2211 N 1st St, L=San Jose, ST=California, OID.2.5.4.17=95131-2021, C=US, SERIALNUMBER=3014267, OID.2.5.4.15=Private

Organization, OID.1.3.6.1.4.1.311.60.2.1.2=Delaware, OID.1.3.6.1.4.1.311.60.2.1.3=US

• #1 Issuer: CN=VeriSign Class 3 Extended Validation SSL CA, OU=Terms of use at https://www.verisign.com/rpa (c)06, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

• #2 Subject: CN=VeriSign Class 3 Extended Validation SSL CA, OU=Terms of use at https://www.verisign.com/rpa (c)06, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

• #2 Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

• #3 Subject: CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

• #3 Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

• WAIT! No Self-Signed Cert!? One reason it helps to pre-load the CA

Truststore…


Find the ROOT

• If it worked in Java or a Browser, your truststore has it (unless you

accept an exception)

• We are looking for : OU=Class 3 Public Primary Certification Authority

I think we found it! – save as ROOT

Issuer = Subject!


Trust, but Verify

Directory of C:\paypalcerts

07/31/2012 03:30 PM 2,280 www_paypal_com_VeriSign_Class_Extended_Validation_SSL_CA.pem

07/31/2012 03:31 PM 2,136 VeriSign_Class_Extended_Validation_SSL_CA_VeriSign_Class_Public_Primary_Certification_Authority_-_G.pem

07/31/2012 03:32 PM 1,756 VeriSign_Class_Public_Primary_Certification_Authority_-_G.pem

07/31/2012 03:36 PM 848 ROOT.

C:\paypalcerts>openssl verify -verbose -CAfile ROOT VeriSign_Class_Public_Primary_Certification_Authority_-_G.pem

VeriSign_Class_Public_Primary_Certification_Authority_-_G.pem: OK

Is ROOT the Issuer for VeriSign_Class_Public_Primary_Certification_Authority_-

_G.pem ? Is ROOT truly self-signed?

C:\paypalcerts>openssl verify -verbose -CAfile ROOT ROOT

ROOT: OK

Yes, and Yes!

We now have a full chain!


Authority Key Identifiers

Server/User Cert: X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

X509v3 Subject Key Identifier:

0E:DB:4D:16:A0:E5:BA:CE:38:90:00:DD:25:51:31:29:5A:31:1B:87

X509v3 Authority Key Identifier:

keyid:4C:47:7E:B4:93:A1:B1:30:A2:2B:FF:B1:96:B7:30:F0:E9:18:69:DF

DirName:/C=US/ST=California/L=Palo Alto/O=TIBCO Software

Inc./OU=Engineering/CN=4KSHA256/[email protected]

serial:A2:6B:0F:3F:02:56:DD:A7

CA Cert: Certificate:

Data:

Version: 3 (0x2)

Serial Number:

a2:6b:0f:3f:02:56:dd:a7

…

Subject: C=US, ST=California, L=Palo Alto, O=TIBCO Software Inc., OU=Engineering,

CN=4KSHA256/[email protected]

…

X509v3 Authority Key Identifier:

keyid:4C:47:7E:B4:93:A1:B1:30:A2:2B:FF:B1:96:B7:30:F0:E9:18:69:DF

DirName:/C=US/ST=California/L=Palo Alto/O=TIBCO Software

Inc./OU=Engineering/CN=4KSHA256/[email protected]

serial:A2:6B:0F:3F:02:56:DD:A7

…


CA:TRUE

Authority Serial #

Has been found!


Public Key Concepts – Identity/Authenticity

• Identity comes from being able to uniquely associate an entity with

some hierarchical elements.

– From X.500: UID, Common Name ([email protected], fqdn.company.com)

• Credentials of the Identity include some means of vouching for the

issuer – a signature or some other mark that makes the identity

„authentic‟

• Trust is based on trusting the issuer and validating the credentials.

• Authentication is at least one of:

– What you know (ID/Password)

– What you have (Passport, Driver‟s License, Private Key)

– What you are (fingerprint, retina scan, voice)

17

mailto:[email protected]


Public Key Concepts – Confidentiality/Encryption

18

Alice Bob

Here is

my public

key..

Perfect!

I will use it

to send you

some info…

privately!

[a7Uq8zbD1]

Using Alice‟s Public Key, Bob can encrypt a message

that only Alice can decrypt.


Public Key Concepts – Integrity/Signatures

19

I‟ll compute

something with a hash

algorithm, then use

my private key

to sign it.

Perfect!

I will then know

that it wasn‟t

modified (integrity)

and that it came

from You!

Using Alice‟s Public Key, Bob can validate the signature

from Alice.


Registration/Certificate/Validation Authorities

EV Certs Extended Validation


Common Terms

• Public Key Infrastructure – an asymmetric scheme to present publicly

useful identity items (public key) while safeguarding unauthorized (non-

identity) use by requiring a private key. Concepts and Processes.

• Public Key Cryptography Standards – the details on how one might

implement PKI.

• Trust Model – generally a chain-of-trust by CA signature verification,

though some applications (e.g., TIBCO Rendezvous) need a trust model

of “holding” (i.e., having a copy means you trust it)

• TrustStore – a collection of Public Keys that are generally Certificate

Authority Keys, but as above, can include Public Server/Client keys

• KeyStore – generally a key-pair of Private + Public Key, but can contain

multiple identities with an „alias‟ as an „index‟.


Common Terms, con‟t

• Encoding

– PEM – Privacy Enhanced Mail – token-delimited Base64 encoded key

– DER – Distinguished Encoding Rule – a binary token

– BER – Basic Encoding Rules – a „raw‟ super-set of DER (not commonly used)

• Asymmetric Operations – a public key may encrypt in such a way as

only the corresponding private key may decrypt; a private key may sign

in such a way that the public key can be used to validate the identity of

the signatory.

• Bulk/Symmetric Encryption – Public Key encryption is expensive, but

needed to convey shared secrets (encryption/confidentiality), and

confirm identities (signatures/integrity). Once a shared secret is

validated, it can be used with Block or Stream ciphers which are often

called „bulk encryption algorithms‟.


PKI & PKCS

• Asymmetric Key schemes are useful, but expensive

• Symmetric Key schemes are less flexible, but cheap

• TLS/SSL uses Asymmetric Keys to share a Symmetric Key „secret‟

sign verify sign/s verify/s

rsa 512 bits 0.000531s 0.000049s 1884.8 20584.2

rsa 1024 bits 0.002684s 0.000143s 372.6 6990.4

rsa 2048 bits 0.015626s 0.000472s 64.0 2117.6

rsa 4096 bits 0.113300s 0.001659s 8.8 602.6

The 'numbers' are in 1000s of bytes per second processed.

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes

des cbc 48155.04k 50526.17k 51495.45k 52127.44k 52891.60k

des ede3 18353.81k 19142.23k 19138.93k 19240.91k 19451.37k

aes-128 cbc 74831.47k 73294.96k 76695.84k 75352.42k 75624.14k

aes-192 cbc 62426.85k 66483.92k 65664.25k 66908.14k 69042.04k

aes-256 cbc 56814.14k 58193.60k 59001.99k 59652.32k 58193.60k

Expensive!

Cheap!


Common PKCS

• PKCS#1 is the RSA Cryptography Standard (RFC 3447)

• PKCS#5 is Password Based Encryption Standard - aka PBE (RFC

2898)

• PKCS#7 is a collection of one or more public keys (RFC 2315)

• PKCS#8 is about private key information syntax (RFC 5208)

• PKCS#10 is about Certificate Request Standard (RFC 2986)

• PKCS#11 is an interface to external/other providers (e.g., Hardware

Security Module)

• PKCS#12 is about PFX Personal Information Exchange a store for

private keys with one or more public keys, often a chain.


Levels of Trust (EMS example)

Less Secure

More Secure Certificate Revocation Check (@Server)

Server Name Match: -ssl_hostname

(-ssl_hostname server.domain.com)

Validate Host: -ssl_trusted

(-ssl_trusted /home/user2/server_root.cert.pem)

Certificate Identity: -ssl_identity

(bi-lateral SSL)

(-ssl_identity /home/user2/client_identity.p12)

Ciphers: -ssl_ciphers

(-ssl_ciphers TLS_RSA_WITH_AES_256_CBC_SHA)

SSL URL: -server ssl://hostname:port

(uni-lateral SSL) – check expiration.

(-server ssl://localhost:7243)

No SSL

(-server tcp://localhost:7222)


Open & Explore PKCS#12

• This one has a full chain that includes a Root CA (self-signed) and an Intermediate

CA C:\OpenSSL\bin\L2>openssl pkcs12 -in forcedimport.p12 –info

Enter Import Password:

MAC Iteration 100

MAC verified OK

PKCS7 Data

Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 100

Bag Attributes

friendlyName: samplecert (level2)

localKeyID: 35 99 57 11 D4 52 AC 4C 79 A3 59 04 70 59 8C D9 51 4B DF DF


Key Attributes: <No Attributes>

Enter PEM pass phrase:

Verifying - Enter PEM pass phrase:

-----BEGIN RSA PRIVATE KEY-----

Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,6AFC0DAD1B09E4D4

[SNIP]

YkauhRg81cvCJ8kB2HE/8ei/Dr+qEKbbpiBHbYnFAxGx2Yoj//mA6dTbcXj/9aQz

-----END RSA PRIVATE KEY-----

PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 100

Certificate bag

Bag Attributes


localKeyID: 35 99 57 11 D4 52 AC 4C 79 A3 59 04 70 59 8C D9 51 4B DF DF


subject=/C=US/ST=CA/O=TIBCO Software Inc./OU=Engineering/CN=samplecert/[email protected]

issuer=/C=US/ST=CA/O=TIBCO Software Inc./OU=Engineering/CN=level2/[email protected]


MIIEJzCCAw+gAwIBAgICAX4wDQYJKoZIhvcNAQEFBQAwgYExCzAJBgNVBAYTAlVT [SNIP]

-----END CERTIFICATE-----

Phrase for Store

PKCS#7

Phrase for Private Key

Subject and Issuer

PKCS#5 PBE

PKCS#7 Bag


PKCS#12 Continued

Certificate bag

Bag Attributes

friendlyName: pseudogod

subject=/C=US/ST=CA/L=Palo Alto/O=TIBCO Software Inc./OU=Engineering/CN=pseudogod/[email protected]

issuer=/C=US/ST=CA/L=Palo Alto/O=TIBCO Software Inc./OU=Engineering/CN=pseudogod/[email protected]


MIIEtzCCA5+gAwIBAgIJALdkmlnwzm3+MA0GCSqGSIb3DQEBBQUAMIGYMQswCQYD

[SNIP]


Certificate bag

Bag Attributes: <Empty Attributes>

subject=/C=US/ST=CA/O=TIBCO Software Inc./OU=Engineering/CN=level2/[email protected]

issuer=/C=US/ST=CA/L=Palo Alto/O=TIBCO Software Inc./OU=Engineering/CN=pseudogod/[email protected]


MIIEyDCCA7CgAwIBAgICAX0wDQYJKoZIhvcNAQEEBQAwgZgxCzAJBgNVBAYTAlVT

[SNIP]


Subject and Issuer

Subject and Issuer

pseudogod level2 samplecert

Root CA/Self-Signed Intermediate CA Leaf Certificate

Cut/Paste Keys Include

-----BEGIN XXX-----

and

-----END XXX-----

samplecert

PUBLIC

PRIVATE

PUBLIC PUBLIC


Trust Items – X.509 Public Key C:\Certificates\2011-FIPS186-3>openssl x509 -in someone-wk.na.tibco.com.cert.pem –text

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 486 (0x1e6)

Signature Algorithm: sha256WithRSAEncryption

Issuer: C=US, ST=California, L=Palo Alto, O=TIBCO Software Inc., OU=Engineering,

CN=4KSHA256/[email protected]

Validity

Not Before: May 24 18:20:56 2011 GMT

Not After : May 23 18:20:56 2013 GMT

Subject: C=US, ST=California, O=TIBCO Software Inc., OU=Engineering, CN=someone-wk.na.tibco.com

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

RSA Public Key: (2048 bit)

Modulus (2048 bit):

00:c6:33:d6:3a:da:52:89:11:80:0d:89:10:1a:0d:3c:df

Exponent: 65537 (0x10001)

X509v3 extensions:


CA:FALSE

X509v3 CRL Distribution Points:

URI:file:///home/tibco/ca/crl.pem

Strong Signature

Trusted Issuer

Time Validity

FQDN of URL

Size of Key

Not a CA

Revoked?


Somewhat “Rare” X.509 Items

• nameConstraints=excluded;IP:10.105.150.234/255.255.254.0

• keyUsage = nonRepudiation, digitalSignature, keyEncipherment,

dataEncipherment, keyAgreement, keycertSign, cRLSign, encipherOnly,

decipherOnly

• SubjectAltName


IETF RFC Requirements

• Different RFCs require different styles of SSL

– RFC 2818 – HTTP Over TLS

– RFC 2595 - "Using TLS with IMAP, POP3 and ACAP"

– RFC 2459 - (PKI, circa 1999)

– RFC 2830 – LDAP/s (must have single FQDN)

• You can have differences such that a single certificate may not be

sufficient!

– Wildcard names for FQDN – only in first level (illegal for LDAP)

• *.na.tibco.com

– Multiple Common Names (rare, illegal for LDAP)

– Subject altNames (legal for LDAP, an alternate to wildcards)


Revocation – CRL & OCSP

• When the formerly good is compromised…or the owners go bad

• Online Certificate Status Protocol (RFC 2560)

– Request sent to responder – response is signed “good or bad” – single

cert/single response Authority Information Access:

OCSP - URI:http://ocsp.digicert.com

• Certificate Revocation List

– PKCS#7 structure which may have many certificates in it

– Burden of parsing is left to the Client

– Can be “online” with a CRL Distribution Point (file://, http://, ldap://) X509v3 CRL Distribution Points:

URI:file:///home/tibco/ca/crl.pem


Flow of using a CA

• Heavy Prime Number BigInt Math creates Public and Private Keys

• Request contains Identity information and Public Key

• Requester maintains secure access to Private Key and sends Request

to CA for signature (actually sends to RA, which sends to CA)

• CA signs the Public Key and returns a “certificate” (Certified)

• Additional Requester functions usually combine Private Key and

Certificate into some form of a store (JKS/JCEKS/PKCS#12), which

may contain the CA public key(s)

• Private Key and Keystore passphrases MAY be different – but caution! –

some applications only accept one passphrase!

• When using OpenSSL, it pays to set up the CNF file to manage indices,

serial numbers, etc. Leverage the framework!

32


Common OpenSSL Routines • REM Make a request for 2048-bit RSA signed by SHA2 using inputs from attributes.txt - no

prompting

• openssl req -newkey rsa:2048 -sha256 -keyout Key.pem -keyform PEM -out Req.pem -outform PEM -config attributes.txt -batch –verbose

• REM encrypt the key

• openssl rsa -in Key.pem -aes128 -out Key-enc.pem -passin env:PASS -passout env:PASS

• REM sign the request

• openssl ca -md sha256 -in Req.pem -out Cert.pem -key password -batch

• pause

• REM make the certificate into PKCS#12 format with the full chain using Priv Key and Export

passwords assigned to env var $PASS or %PASS%

• openssl pkcs12 -aes128 -export -descert -chain -in Cert.pem -out alice-sha256.p12 -inkey Key-enc.pem -CAfile cacert-4096-sha256.pem -name "alice-256" -passin env:PASS -passout

env:PASS

• Reading a PKCS#12:

– openssl pkcs12 -in alice2.p12 –info

• Reading an X.509:

– openssl x509 -in alice1.cert.pem -text


Tools, Troubleshooting, Cold Facts

• Switch Providers for 2nd Opinion (or to overcome limitations)

– Some J2SE packages (e.g., LDAP, JDBC) were incompatible with Entrust +

Java SE 6

– Some functions are NOT in our GUI, but can be configured for the provider with

properties

– Different Debug/Trace details

• Dealing with Antiques:

– Keytool creates X.509v1 certificates – Entrust doesn‟t trust them (add a

property) • java.property.com.entrust.toolkit.x509.CertVerifier.ForceV1CertAsCA true

• Mainframes seem to be happier with DER-encoded certificates,

rejecting PEM

– With large key sizes (>2K), a mainframe might have a starved LPAR and fail to

finish a handshake in time.

• Not all systems accept all types of keys

– BW, when using Cert/Key, wants a PKCS#8 Private Key – PEM won‟t work


Java Property Examples • Change TIBCO Provider from default/Entrust to J2SE, and debug

– java.property.javax.net.debug=ssl

– java.property.TIBCO_SECURITY_VENDOR=j2se

• Setting SSL+ properties for Oracle JDBC Activities in BW – java.property.oracle.net.tns_admin=C:/temp/tnsnames.ora

– javax.net.ssl.trustStore=C:/tibco/jre/1.6.0/lib/security/cacerts

– javax.net.ssl.trustStorePassword=changeit

– java.property.oracle.net.ssl_cipher_suites=TLS_RSA_WITH_AES_256_CBC_SHA

– java.property.oracle.jdbc.Trace=true

• OCSP/CRL Functions – java.property.java.security.ocsp.enable=true

– java.property.com.sun.net.ssl.checkRevocation=true

– java.property.com.sun.security.enableCRLDP=true

– java.property.com.tibco.security.NoExplicitCAChain=true

– java.property.com.tibco.security.CheckRevocation=true

– java.property.java.security.debug=certpath

– java.property.java.security.ocsp.responderURL="http://someone-wk.na.tibco.com:8888"


Property Examples – con‟t

• For BusinessWorks

– Trace.Task.*=true (Client side SSL tracing information is made available)

– bw.plugin.http.server.debug: true (Server side SSL tracing information is

made available)


Challenge Yourself

• Get the Full Chain from https://www.paypal.com and

https://tibco.tibbr.com

• Create your own CA with a Self-Signed Cert X.509v3, 2048-bit RSA,

and signed with SHA-256

– Make a personal certificate for <yourID>@tibco.com, same bit-length and SHA

algorithm (e.g., [email protected])

– Make a certificate for your machine(s), use the FQDN (e.g., someone-

wk.na.tibco.com)

– Make PKCS#12 structures with the chain included, use AES-128 to secure the

store.

– Copy the Private Key into PKCS#8 format

– Copy the Public Key into PKCS#7 format

– Import your key pair into a JKS or JCEKS

– Copy your Public Key into DER encoding (or if you did it in DER, make it PEM)

– Make a certificate with the OCSP/CRL information, then revoke it and test the

revocation.

• Play, Play, Play – Learn, Learn, Learn

37

https://www.paypal.com/

https://tibco.tibbr.com/


Appendix

38


Brief History – SSL/TLS

• 1993/4 – SSLv1: Developed by Netscape, never released

1995 – SSLv2 – short-lived as it was scrutinized and security flaws were

found

1995/6 – Microsoft offers PCT (Private Communications Technology) to

counter SSLv2 flaws

1996 – SSLv3

1999 – TLSv1.0 (aka SSLv3.1)

2002 – Vulnerabilities in CBC mode are postulated with TLSv1.0, but

not proven

2006 – TLSv1.1 – better checks against padding errors and CBC

exploits (Java SE 6)

2008 – TLSv1.2 – Integrity moves from SHA-1 to SHA-256, new cipher

suites (Java SE 7 - Elliptical Curve)

2011 – Browser Exploit Against SSL/TLS (BEAST) – Renegotiation –

Cipher-Block Chaining exploit proven - RC4 was not vulnerable (stream

cipher)


Standards Advance…

• NIST has competitions for encryption and hashing

• DES/TDES aged, then came Advanced Encryption Standard (AES)

based on Rijndael

• MD5 aged, then SHA-1, then SHA-2…SHA-3 is in current competition

(started 2007)

• Export Rules/Department of Commerce – Export Ciphers & Unlimited

Strength Policy

• FIPS 140-2 2001 -> FIPS 140-3 Draft 2009

• 2011 NIST Standards for Key Size and related TLS specs

– Years 2011-to-2030:

• Minimum Key Size: 2048

• Hashing Minimum: SHA-1 for TLS

• Elliptical Curve: 224

• 2010 NIST sunsets SHA-1 for Digital Signatures

• Various Governments and Industries adopt 2048 keys signed with SHA-

2 algorithm (usually SHA-256)


Standards Morph

• ISO OSI – ISO/IEC 7498-1 – “The OSI Model” & GOSIP (Government

Open Systems Interconnection Profile) – circa 1984, reasonable

adoption by 1992, almost dead by 1996.

– TP4, X.400 Mail, X.500 Directory Service, FTAM, VT, CMISE, CMIP

• Today, not much remains…

– MAC-level Addressing from OSI is part of IPv6

– X.500 lost some weight with Lightweight Directory Access Protocol (LDAP)

• We kept X.509! Certificates/CRLs can be stored/retrieved in LDAP.


Federal Information Processing Standard 140-2 • Four Levels

– Level 1: approved algorithms, non-interference, self-check

– Level 2: tamper evidence

– Level 3: tamper detection/response (zeroize all critical security parameters)

– Level 4: higher authorization (quorum w/smart cards), environmental safeguards

• TIBCO Runtime Agent w/Entrust Authority Security for the Java Platform

v7.2

– http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#802

– TRA file entry: java.property.com.tibco.security.FIPS=true

• TIBCO Enterprise Message Service OpenSSL with FIPS Object Module

1.2+

– http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1051

– Main configuration file entry: FIPS140-2 = true

• Restrictions – see documentation. EMS Java samples must use Entrust as

provider and cannot use their own PRNG (in user code); TRA must NOT

use TIBCO_SECURITY_VENDOR=j2se •

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm











Unlimited Strength Jurisdiction Policy

• local_policy.jar and US_export_policy.jar (signed) get replaced in

<JRE>/lib/security

• default_local.policy

– Standard // Some countries have import limits on crypto strength. This policy file

// is worldwide importable.

grant {

permission javax.crypto.CryptoPermission "DES", 64;

permission javax.crypto.CryptoPermission "DESede", *;

permission javax.crypto.CryptoPermission "RC2", 128,

"javax.crypto.spec.RC2ParameterSpec", 128;

permission javax.crypto.CryptoPermission "RC4", 128;

permission javax.crypto.CryptoPermission "RC5", 128,

"javax.crypto.spec.RC5ParameterSpec", *, 12, *;

permission javax.crypto.CryptoPermission "RSA", *;

permission javax.crypto.CryptoPermission *, 128;

};

– Unlimited Strength // Country-specific policy file for countries with no limits on crypto strength.

grant {

// There is no restriction to any algorithms.

permission javax.crypto.CryptoAllPermission;

};


TLS/SSL Handshake

CLIENT Directionality SERVER

1. Client Hello

2. Server hello

3. Certificate

4. Certificate Request

5. Server Key Exchange

6. Server hello done

7. Certificate

8. Client Key Exchange

9. Certificate Verify

10. Change cipher spec

11. Finished

12. Change cipher spec

13. Finished

14. Encrypted Data 14. Encrypted Data


Handshake in Gory Detail

• Client Hello Message

– Version Number – version 3.1 indicates TLS

– Randomly Generated Data – a ClientRandom(32) is a 4 byte number of

timestamp plus 28 bytes of random data used with the server‟s random to

generate a master secret from which keys are derived.

– Session Identification (optional) to resume a previous session

– Cipher Suite – a list of ciphers available to client.

– Compression Algorithm (optional)

• Server Hello Message – essentially the same info.

• Server Certificate – contains Server‟s Public Key used to authenticate

Server to Client

• Server Key Exchange (optional)

– Server creates and sends a temporary key to client which may be used to

encrypt the Client Key Exchange later on.


Long Handshake Continues… • Client Certificate Request (optional)

• Server Hello done

• Client Certificate (if required/requested)

• Client Key Exchange

– Client computes a „pre-master‟ secret using both random values

– Pre-master is encrypted by the public key from Server

– Both parties compute the master secret and derive a session key

• If the server can decrypt the data and complete the protocol, the client is assured that the

server has the right private key.

• Certificate Verify

– Only when Client sends a certificate – client uses its private key to sign a hash

of all messages sent up to this point; verified with public key

• Change Cipher Spec

– Notification to Server that all messages will use the keys and algorithms

negotiated.

tls/ssl primer: protocols, x.509, pkcs, and tools€“ asymmetric and symmetric keys – rsa/dsa...

Documents