secure communication with z/os via tls jamieson walker

Secure Communication with z/OS via TLS

Jamieson Walker

Do you feel safe when you use the internet?

Broadcom Proprietary and Confidential. Copyright © 2020 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its

subsidiaries.

Are your communications safe when you use the Web?

A few years ago I bet the community consensus

would be NO. Passwords, IDs and data were

transmitted across local and wide area networks

in plain text.

Enter TLS(SSL). Described in 1995, started to

become ubiquitous in 2015 when google started

favoring HTTPS sites of HTTP sites.

We want our web communications to be safe, we

need our business data to be safe while in

motion.


subsidiaries.

What is TLS?

• Transport Layer Security

• In combination with a key infrastructure

(PKI) it enables computers to do something

that cannot be done any other way

• Information can be sent confidentially

(encryption)

• Guarantee information will arrive

unchanged (integrity)

• Authenticate the sender and the receiver

(identity)


subsidiaries.

Terminology

• TLS - may also be referred to as SSL or

HTTPS, underlying technology is the same

• Entity - a party that exists, logically or

physically (a server or application)

• Identity - collection of attributes that

describe an entity

• Identifier - a reference used to uniquely

identify an entity (name)

• PKI - Public Key Infrastructure


subsidiaries.

Terminology (cont’)

• Authenticate - verify that some claim is true

• Certificate - An object that binds a party to

an identity(public key)

• Certificate Authority - a trusted party that

issues certificates

• Root Certificate - the final certificate in a

chain of trust

• Intermediate Certificates - subordinate

certificates signed by root certificate

• End entity certificates - certificates

identifying an entity, signed by intermediate

certificates

• Check out RFC 4949 if you would like to

learn more PKI terminology


subsidiaries.

To understand TLS we must understand Certificates


subsidiaries.

Certificates

• Bind an entity to a public key

• Certificate authority can vouch for an

entities’ identity

• Signed by the issuer with their private key,

thus you can verify its signature

• A certificate signed by a trusted CA allows

you to trust the certificate. It is like an

introduction by a mutual friend, or the

foreword in a book.

• The term “certificate” is referring to x.509

certificates in most cases


subsidiaries.

PKI - Public Key Infrastructure

• How certificates are created and leveraged:

provides the majority of value of binding

names to public keys

• Two main flavors: internal PKI or Web PKI

• Web PKI is defined by RFC 5280 and CAB

(certificate authority browser), they are used

by browsers for HTTPS and almost

everything that uses TLS

• Internal PKI is defined by you(organization).

Allows you to identify, authenticate and

establish cryptographic connections with

your components even on public internet


subsidiaries.

Trust?

• How can we trust an entity we have never

met?

• Trust store: a pre-installed (or configurable)

list of trusted root certificates.

• Where does the trust start? Bootstrapping

• Trust starts at a root certificate that is self

signed

• A trust store is only valid if the certificates

inside it got there in a trusted manner

• Note when we trust Certificate authorities

we are not saying they are morally

trustworth

• Internal PKI truststores should be kept

separate from web PKI truststore


subsidiaries.

Certificate Authority and Trust

• Trusted certificate issuers

• Vouch for binding between public key and

name with a signature

• CAs are essentially just certificates

• Certificates have a root certificate and chain

down from there with intermediate

certificates until you get to your end entity

certificate

• The root certificate is a CA’s most value

possession.

• A final certificate bundle contains end entity

certificate, intermediate certificate and

finally the root certificate


subsidiaries.

Note: do not disable certificate path

validation, it is critical!

Owners Name

Owners Public key

Issuer’s (CA’s) Name

Issuer’s signature

Root Certificate

Owners Name

Owners Public key



Intermediate Certificate

Owners Name

Owners Public key



End-entity Certificate

sign

sign

Self-signed

Certificate chain of trust


subsidiaries.

Final notes on Certificates

1. Place entity name in “subject alternative

name” extension, stay away from the CN

field - commonly domain name, email

address, IP address or URI

2. Generate key pair with elliptic curve ECDSA

3. Create a certificate signing request -

contains public key and name to be bound

to

4. Send to a trusted CA and pay, they will

verify that you have the right to the name

and sign

5. Set reasonable expiration dates on

certificates

6. Certificates can be revoked but it is an out

of band process that must be implemented

by the client


subsidiaries.

Encryption and Integrity

• Asymmetric encryption• A key for encrypting(public)

• A different key for decrypting(private)

• Symmetric encryption - one key is used for

encryption and decryption

• MACs - message authentication code, used

to ensure that no bit of data is changed

• Feed a message and a secret into HMAC to

receive a MAC

• Consumer feeds the received message into

HMAC with the same secret -> the resulting

MAC should be identical


subsidiaries.

Now TLS

• TLS is an encryption protocol for secure

internet communication

• Comes in 2 prominent flavors in of 2020 -

TLS 1.2 and TLS 1.3

• Consists of a handshake protocol

See https://tls.ulfheim.net/ for an byte-by-byte

illustration of TLS

https://tls.ulfheim.net/


subsidiaries.

Basic process

• Establish TCP connection

• Decide on a version of TLS to use

• Select a cipher suite

• Authenticate the identity of server (and

sometimes client) with servers public key

and SSL certificate CA digital signature

• Generate sessions key for symmetric

encryption

Unencrypted

Encrypted


subsidiaries.

TLS Handshake

Client Server

TCP Connection

1

2

3

Client hello

Server hello

Client certificate request

Client Certificate

Client key info

4

5

Certificate verify

7

8

Client ready

Server ready

6

6


subsidiaries.

1) Client hello

• Initiates handshake with a “hello” including:

• Supported TLS versions

• Supported cipher suites

• Client random

2) Server hello

• Reply containing:

• Server SSL Certificate

• Chosen cipher suite

• Server random


subsidiaries.

3) Authentication

• Client checks server SSL certificate against

CA’s in trust store

• By doing so the client confirms that the

server is who they claim to be and who the

client expected them to be

3.5) Client Authentication

• Used in mutual TLS

• Client sends its SSL certificate information

to server

• Server checks data against CA’s in its trust

store to verify client identity

• Rare use-case in Web


subsidiaries.

4) Premaster secret

• Client sends one additional random string of

bytes

• Encrypts the secret with server public key

• Server can decrypt this secret with its

private key

• Remember the servers public key is

obtained from the certificate the server sent

5) Private key used

• Server decrypts the secret with its private

key


subsidiaries.

6) Session keys created

• Server generates session keys

• Client generates session keys

• Generated separately but will be identical

• Leverages same 3 pieces on both ends:

• Client random - publicly known

• Server random - publicly known

• Premaster secret - publicly unknown

• Enables forward security


subsidiaries.

7) Client ready

• Client sends “finished” message

• “Finished” message is encrypted with

session key

8) Server ready• Server sends “finished” message

• “Finished” message encrypted with session

key

9) Handshake completed

• TLS handshake is done

• All communication for the rest of the

connection uses the session key


subsidiaries.

TLS Handshake

Client Server

TCP Connection

1

2

3

Client hello

Server hello

Client certificate request

Client Certificate

Client key info

4

5

Certificate verify

7

8

Client ready

Server ready

6

6


subsidiaries.

Broadcom is leveraging TLS

• Security Insights(SI)

• MTC- A and MTC-DB

• ESM Microservice

• Data Content Discovery (DCD)

• Compliance Event Manager (CEM)

• Trusted Access Manager for Z (TamZ)

Thank

[email protected]

1 (630) 487-0519

secure communication with z/os via tls jamieson walker

Documents