SSL TLS Primer-TIBCOmmunity

TLS/SSL PRIMER:
PROTOCOLS, X.509, PKCS, AND TOOLS
TIBCO Software Inc.
Copyright 2000-2012 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 isnt in all CA/Intermediate/Root
certificates
Fool-proof is to use the CAs 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
IE9
FF12
Ch 21
tibco.tibbr.coms True Chain

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//emailAddress=info@valicert.com
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 (cont)

1 of 3 Certificates
PEM Encoding
Portecle (cont)
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
Issuer = Subject!
I think we found it! save as ROOT

Trust, but Verify

Directory of C:\paypalcerts
07/31/2012
07/31/2012
07/31/2012
07/31/2012
03:30
03:31
03:32
03:36
PM
PM
PM
PM
2,280
2,136
1,756
848
www_paypal_com_VeriSign_Class_Extended_Validation_SSL_CA.pem
VeriSign_Class_Extended_Validation_SSL_CA_VeriSign_Class_Public_Primary_Certification_Autho
VeriSign_Class_Public_Primary_Certification_Authority_-_G.pem
ROOT.
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 VeriSign_Class_Public_Primary_Certification_Authority_-_G.pem
VeriSign_Class_Public_Primary_Certification_Authority_-_G.pem:
OK
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/emailAddress=someone@tibco.com
serial:A2:6B:0F:3F:02:56:DD:A7
Authority
Serial #
CA Cert:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
Has been
a2:6b:0f:3f:02:56:dd:a7
Subject: C=US, ST=California, L=Palo Alto, O=TIBCO Software Inc., OU=Engineering,

CN=4KSHA256/emailAddress=someone@tibco.com
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/emailAddress=someone@tibco.com
serial:A2:6B:0F:3F:02:56:DD:A7

CA:TRUE
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 (id@company.com, 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, Drivers License, Private Key)
What you are (fingerprint, retina scan, voice)
17
Public Key Concepts Confidentiality/Encryption
Alice
Bob
Here is
my public
key..
[a7Uq8zbD1]
Perfect!
I will use it
to send you
some info
privately!
Using Alices Public Key, Bob can encrypt a message

that only Alice can decrypt.
18
Public Key Concepts Integrity/Signatures
Ill compute
something with a hash
algorithm, then use
my private key
to sign it.
Perfect!
I will then know
that it wasnt
modified (integrity)
and that it came
from You!
Using Alices Public Key, Bob can validate the signature

from Alice.
19
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 (nonidentity) 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, cont

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
rsa 512 bits

rsa 1024 bits
rsa 2048 bits
rsa 4096 bits
sign
0.000531s
0.002684s
0.015626s
0.113300s
verify
0.000049s
0.000143s
0.000472s
0.001659s
sign/s verify/s
1884.8 20584.2
372.6
6990.4
64.0
2117.6
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)

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)
Less Secure
Open & Explore PKCS#12

This one has a full chain that includes a Root CA (self-signed) and an Intermediate
CA
Phrase for
Store
PKCS#7
PKCS#5 PBE
Phrase for
Private Key
PKCS#7 Bag
Subject and
Issuer
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/emailAddress=someon
issuer=/C=US/ST=CA/O=TIBCO Software Inc./OU=Engineering/CN=level2/emailAddress=someone@tib
-----BEGIN CERTIFICATE----MIIEJzCCAw+gAwIBAgICAX4wDQYJKoZIhvcNAQEFBQAwgYExCzAJBgNVBAYTAlVT [SNIP]
-----END CERTIFICATE---- Copyright 2000-2012 TIBCO Software Inc.
PKCS#12 Continued
Subject and
Issuer
Subject and
Issuer
Certificate bag
Bag Attributes
friendlyName: pseudogod
subject=/C=US/ST=CA/L=Palo Alto/O=TIBCO Software Inc./OU=Engineering/CN=pseudogod/emailAddress=someone@tibco.com
issuer=/C=US/ST=CA/L=Palo Alto/O=TIBCO Software Inc./OU=Engineering/CN=pseudogod/emailAddress=someone@tibco.com
-----BEGIN CERTIFICATE----MIIEtzCCA5+gAwIBAgIJALdkmlnwzm3+MA0GCSqGSIb3DQEBBQUAMIGYMQswCQYD
[SNIP]
-----END CERTIFICATE----Certificate bag
Bag Attributes: <Empty Attributes>
subject=/C=US/ST=CA/O=TIBCO Software Inc./OU=Engineering/CN=level2/emailAddress=someone@tibco.com
issuer=/C=US/ST=CA/L=Palo Alto/O=TIBCO Software Inc./OU=Engineering/CN=pseudogod/emailAddress=someone@tibco.com
-----BEGIN CERTIFICATE----MIIEyDCCA7CgAwIBAgICAX0wDQYJKoZIhvcNAQEEBQAwgZgxCzAJBgNVBAYTAlVT
[SNIP]
-----END CERTIFICATE-----
PUBLIC
PUBLIC
pseudogod
level2
Root CA/Self-Signed
Intermediate CA
PUBLIC
samplecert
Leaf Certificate
samplecert
PRIVATE
Cut/Paste Keys
Include
-----BEGIN XXX----and
-----END XXX-----
Trust Items X.509 Public Key
Strong
Signature
Trusted Issuer
Time Validity
FQDN of URL
Size of Key
Not a CA
Revoked?
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/emailAddress=someone@tibco.com
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
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 compromisedor 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 doesnt 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 wont 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 cont

For BusinessWorks
(Client side SSL tracing information is made available)
bw.plugin.http.server.debug: true (Server side SSL tracing information is
made available)
Trace.Task.*=true
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., someone@tibco.com)
Make a certificate for your machine(s), use the FQDN (e.g., someonewk.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
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-2SHA-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 SHA2 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:
Level 2:
Level 3:
Level 4:
approved algorithms, non-interference, self-check

tamper evidence
tamper detection/response (zeroize all critical security parameters)
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
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 servers 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 Servers 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.

SSL TLS Primer-TIBCOmmunity

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SSL TLS Primer-TIBCOmmunity

Încărcat de

Drepturi de autor:

Formate disponibile

TLS/SSL PRIMER:

PROTOCOLS, X.509, PKCS, AND TOOLS

TIBCO Software Inc.

Copyright 2000-2012 TIBCO Software Inc.

Finding the Chain of Trust

Basic Concepts: Identity, Integrity, Confidentiality

TLSv1 Handshake Unilateral vs. Bilateral/Mutual Authentication

Flow of Using your own CA

Copyright 2000-2012 TIBCO Software Inc.

Finding the Chain-of-Trust

Copyright 2000-2012 TIBCO Software Inc.

TLS/SSL is at the Transport Level

Copyright 2000-2012 TIBCO Software Inc.

Getting a Chain with a Browser

Copyright 2000-2012 TIBCO Software Inc.

Copyright 2000-2012 TIBCO Software Inc.

Copyright 2000-2012 TIBCO Software Inc.

Browser False Chains tibco.tibbr.com

Copyright 2000-2012 TIBCO Software Inc.

tibco.tibbr.coms True Chain

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

Copyright 2000-2012 TIBCO Software Inc.

Finding the Chain-of-Trust - OpenSSL showcerts

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

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

Copyright 2000-2012 TIBCO Software Inc.

Finding the Chain-of-Trust - Portecle

Copyright 2000-2012 TIBCO Software Inc.

Chain with Portecle (cont)

Copyright 2000-2012 TIBCO Software Inc.

#1 Issuer: CN=VeriSign Class 3 Extended Validation SSL CA, OU=Terms of use at

#2 Subject: CN=VeriSign Class 3 Extended Validation SSL CA, OU=Terms of use at

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

Copyright 2000-2012 TIBCO Software Inc.

Find the ROOT

I think we found it! save as ROOT

Trust, but Verify

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

Yes, and Yes!

Authority Key Identifiers

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

X509v3 Authority Key Identifier:

X509v3 Basic Constraints:

Copyright 2000-2012 TIBCO Software Inc.

Public Key Concepts Identity/Authenticity

Credentials of the Identity include some means of vouching for the

Copyright 2000-2012 TIBCO Software Inc.

Public Key Concepts Confidentiality/Encryption

Using Alices Public Key, Bob can encrypt a message

Public Key Concepts Integrity/Signatures

Using Alices Public Key, Bob can validate the signature

Copyright 2000-2012 TIBCO Software Inc.

Copyright 2000-2012 TIBCO Software Inc.

Common Terms, cont

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

Copyright 2000-2012 TIBCO Software Inc.

PKI & PKCS

rsa 512 bits

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

Copyright 2000-2012 TIBCO Software Inc.

Copyright 2000-2012 TIBCO Software Inc.

Levels of Trust (EMS example)