Norbert Muehr (Siemens PLM GTAC EMEA)

Transcription

1 Presentation date: Presenter name: Room name: Presentation title: Norbert Muehr (Siemens PLM GTAC EMEA) Room Paris Hardening SSL Configuring a Teamcenter-System for Perfect Forward Secrecy PLM Europe 2018 All rights reserved Your name/company Your name/company Page 1

2 Although, for many companies using encrypted communication has become an IT security principle, much of the data sent across the globe still uses weak encryption which is in danger of getting recorded and decrypted by external parties to steal information. This presentation will focus on the TLS/SSL implementation of elliptic curve cryptography in Teamcenter and related PLM applications. Currently, EC cryptography is stronger encryption than the commonly used RSA-based encryption if its correctly applied. Abstract The presenter will try to illustrate the many influencing factors such as Browsers, Operating systems and middleware creating risks which limit the strength of the encryption and the level of security gained.

3 Agenda: 01. Why hardening SSL/TLS configurations 02. Comparison of RSA and Elliptic Curve cryptography 03. Which connections we cover in this presentation (TC System Architecture) 04. Level of security is the result of a negotiation 05. Sample Configuration: 4Tier RichClient - WebTier 06. Sample Configuration: FCC-FSC 07. Sample Configuration: NX 4Tier to TC Webtier

4 Why hardening SSL/TLS configurations Various parties are interested to get intellectual property from companies: Intelligence Services of countries or hacking groups doing business with them Have replicated access to Internet exchange points or large backbone providers Establish replication at Submarine communications cables or use satellites for this Hence affect especially WAN communication between offices and sites Try to decrypt communication and record what they cannot decrypt for later playback and cracking Organized Crime, Individual hackers or hacking groups selling to competitors Often attack from inside the LAN Page 6

5 Why hardening SSL/TLS configurations The consequence: In large companies or in open Internet, data is in high risk to be revealed during the transport. Hence, SSL/TLS is not enough! It should be state of art SSL/TLS! The structure and quality of a TLS connection is determined by the Cipher suite asynchronous synchronous Key Exchange Authentication (certificate key) Bulk Ciphers (transport) Message Authentication Code (integrity) Page 7 Technical life cycle

6 Synchronous versus asynchronous encryption asynchronous synchronous public private common Page 8

7 Life cycle of encryption algorithm Developed in lab Removed by software vendors Defined as standard Cracked realtime in datacenter Adopted by major software vendors operating systems, browsers, middleware, cloud providers Page 9 Cracked in lab vulnerable careless software providers Innovation of hardware (Moore s law, quant computers) Published weaknesses of algorithm

8 Evolution of SSL/TLS protocols TLS 1.0 TLS 1.2 TLS 1.3 Robot attack Weaker please! SSL 3.0 Weak session tickets 0-RTT Governments Weaker please! BANKS Faster please! Poodle attack BEAST attack CRIME attack Heartbleed attack (Open SSL related) Page 10

9 Comparison of RSA and Elliptic Curve cryptography To put things into perspective, according a Universal Security study of 2013, breaking a 228-bit RSA key would take less energy than what is needed to boil a teaspoon of water. Alternatively, breaking a 228-bit ECC key would require more energy than it would take to boil all the water on earth. [taken from ] Key Exchange (Over insecure connection) Authentication (private and public key) Bulk Ciphers (symmetric encryption during transport) Message Authentication (integrity) Page 11 In focus of this presentation!

10 Comparison of RSA and Elliptic Curve cryptography RSA asymmetric key (private + public) one key during the entire communication Key is created by prime number factorization ECC asymmetric key (private + public + curve) various keys during the entire communication All keys get calculated by a particular elliptic curve Bit size When key is cracked, entire communication can be decrypted if not now, than in future from recorded communication with better technology Higher performance during encryption Lower performance during encryption, but mostly acceptable when properly configured When key is cracked and a suitable algorithm is used, only a portion of communication can be decrypted even in future, hence its called ->see Perfect Forward Secrecy Page 12

11 Comparison of RSA and Elliptic Curve cryptography ECC 256 bit key size 384 bit key size (top secret) RSA 3072 bit key size to be equally strong 7680 bit key size to be equally strong Page 13

12 What is perfect Forward secrecy (PFS)? Current Gold standard in available strong encryption Based on the Ephemeral Diffie-Hellman algorithm (ECDHE) Ephemeral means not static since each new TLS session uses a new key on the same elliptic curve Preventing some known to-be-vulnerable ECC algorithms Due to the strength, preferred by banks, military and other security-sensitive uses cases Consider: As in any ECC, Security level depends on which curve is picked As in any encryption, Security level depends on the bit-size of the keys How long is a TLS session? Page 14

13 Target Cipher TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 Naming get my keys through the evil internet via Create my private and public key via Encrypt all the data being transferred after handshake using shared secret Checksum to prevent modificatio n during transport GCM better than CBC Page 15

14 Why does that relate to Teamcenter? Teamcenter got a distributed architecture Much of the communication between the elements of this architecture communicate via TCP and support SSL/TLS. Many customers of Teamcenter work hard to protect their intellectual property and need to exchange data across offices and countries. Most of the manuals and white papers, I read in the past base on the weaker RSA encryption. Large enterprise TLS encryption Teamcenter web tier behind reverse proxies SME TLS encryption Teamcenter web tier involved in TLS communication Page 16 PS: By the way, SSL and TLS are both technologies for encrypted communication. Still many people say SSL when they mean TLS.

15 Client-Server handshake TLS Client (3) Verify server cert, check crypto params (1)Client Hello Supported ciphers, protocol version, random no#1 with time, session ID (2) Server Hello Selected ciphers, Cert (public key), random no#2, session ID Client cert request (2way) (4) Client key exchange Send secret key (Pre-Master Secret, encrypted with public key) (7) Client finished (5) Send client cert (2way) TLS Server (6) Verify client cert (2way) (8) Server finished (9) Exchange messages Encrypted with shared key Page 17

16 What do we have at the end of handshake? TLS Client TLS Server Public key of server Private, Public key of server Master secret Master secret Bulk-Key MAC-Key Bulk-Key MAC-Key Cipher Suite agreed by client and server Protocol agreed by client and server Cipher Suite agreed by client and server Protocol agreed by client and server Page 18

17 Honour order! Cipher negotiation TLS Client Boo, I have sniffed (recorded) your handshake! TLS Server (1)Client Hello Cipher list client could be browser i.e. Chrome for AWC Java JSSE Schannel (windows) Another web server Supported cipher (2) Server Hello Selected ciphers Cipher list server 1. My best cipher 2. My second-best cipher 3. My worst acceptable cipher Sorry, I am old and don t know new ciphers Old server--> old ciphers! Page 19 Old client--> old ciphers! No common Cipher: Handshake failed!

18 TLS 1.2 Resumed sessions - session tickets/ids Solutions: Use TLS 1.3 Disable SessionTickets Tomcat: Only for APR connector IIS: Powershell: Disable-TlsSessionTicketKey 1. Resumed connections don't perform any Diffie-Hellman exchange 2. Session Tickets contain the session keys of the original connection, so a compromised Session Ticket lets the attacker decrypt not only the resumed connection, but also the original connection. 3. Session Tickets are sent in the clear at the beginning of the original connection. 4. Some J2EE web servers offer modifications of session ID handling Page 20

19 Influencing factors on strength of TLS implementation Bit size of algorithm (configuration) Consider Client-Server negotiation (configuration) Prevent old browsers, require fallback to worse ciphers If IE is used, consider influence of Schannel settings Software versions Check Web server config in detail Cipher Suite list as strict as possible and ordered PFS, frequency of new TLS sessions OpenSSL version should be very latest (after update, regen keys!) Download Or Enable latest Java version with Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction where possible After finishing configuration and TLS connection works, test the used cipher suites with Wireshark!! If you are paranoid, also consider the strength and algorithm of your CA cert and intermediate certs and check which root certs are installed in your OS. Page 21

20 (Teamcenter) PFS Implementation steps JSSE-Versions Test TLS clients: 1 1 supported ciphers Protocols Avail. Root certs Required cert format 2 Updated client list 2 Distribute certs (signed public keys) for server+interm. + root In required key store formats Test TLS servers: supported ciphers Protocols Avail. Root certs Required cert format Check whether config can be improved Updated server list Generate server keys and/or buy them Download root certs and interm. certs Set encryption targets desired ciphers desired protocols Cert vendor (own, commercial, Let s Encrypt) Expected performance reduction (measure unencrypted) 3 Simple tests: Resulting Ciphers Performance impact Refresh every 2 years 7 (Pen tests) Stealing priv. keys Common TLS attacks Page 22

21 Test implementation 1 - Root Key generation Generally, keys maybe generated using OpenSSL or JAVA EC keys only possible in OpenSSL! Create my own CA: Create root cert: openssl.cnf CA config settings openssl ecparam -name prime256v1 -out rootca_param.pem openssl ecparam -in rootca_param.pem -genkey -noout -out rootca_key.pem openssl req -config openssl.cnf -key rootca_key.pem -new -x509 -days sha384 -subj "/C=DE/ST=Hessen/L=Frankfurt/O=SPLM/OU=GTAC-EMEA/CN=GTAC ROOT CA" -out rootca_cert.pem openssl pkcs12 -export -in rootca_cert.pem -inkey rootca_key.pem -nokeys -name root -out trust.p12 -password pass: generate rootca_key.pem copy rootca_cert.pem copy trust.p12 pw: Page 23

22 Test implementation 2 Server Key generation Create main cert: openssl.cnf CA config settings openssl ecparam -name prime256v1 -out prime256v1_param.pem openssl ecparam -in prime256v1_param.pem -genkey -noout -out prime256v1_key.pem openssl req -new -sha384 -key prime256v1_key.pem -out prime256v1_key.csr -subj "/C=DE/ST=Hessen/L=Frankfurt/O=SPLM/OU=GTAC- EMEA/CN=decgnvsrv" openssl ca -config openssl.cnf -extensions server_cert -in prime256v1_key.csr -days 375 -keyfile rootca_key.pem -notext -md sha256 - notext -batch -cert rootca_cert.pem -out prime256v1_cert.pem (openssl req -in prime256v1_key.csr -text -noout) generate rootca_key.pem Often you would pay a commercial vendor for that step prime256v1_param.csr create prime256v1_key.csr signed prime256v1_cert.pem trust Page 24

23 Test implementation 3 - Which key store for which purpose? For Tomcat Server: JKS, PKCS11 or PKCS12 keystore PW: prime256v1_cert For Java JSSE Client JKS truststore cacerts PW:.. rootca_cert For Tomcat Server: JKS, PKCS11 or PKCS12 truststore PW: rootca_cert For NX-cURL No keystore, just pem file rootca_cert default CA Root certs Versisign, Thawte, Lets Encrypt, default CA Root certs Versisign, Thawte, Lets Encrypt, Page 25

24 Teamcenter PFS Implementation overview 4-Tier RAC HTTP HTTPS (PFS) SOA NX pkcs12 file CURL Thin Client in browser: IE11 Windows keystore Schannel SSP->OS Named PIPE (Secured OS Pipes to TCCS) Client Tier TCCS TcServerProxy Truststore FCC Java JSSE TcMEM Keystore OpenSSL Root CA PEM file RootCA key ( ) Main PEM file Web Tier NIO Connector BIO Connector APR Connector Java JSSE OpenSSL Tomcat 8 WAS Keystore Truststore Java JSSE Jetty FSC Main key NX pkcs12 file Main cert (Pub) Enterprise Tier Page 26 Teamcenter Server Manager TCServer FSCproxy CURL Java JSSE Boo, I have hacked your server and stolen your private keys Java 8 JSSE Truststore

25 Teamcenter Large company TLS Implementation overview HTTP 4-Tier RAC Thin Client in browser: IE11 HTTPS (PFS) SOA Windows keystore Schannel SSP->OS Named PIPE (Secured OS Pipes to TCCS) TCCS TcServerProxy FCC TcMEM Client Tier Truststore Java JSSE Keystore Reverse proxy Web Tier NIO Connector BIO Connector APR Connector Java JSSE OpenSSL Tomcat 8 WAS Keystore Truststore Java JSSE Jetty FSC Enterprise Tier Teamcenter Server Manager TCServer Page 27 FSCproxy

26 Cipher Suite testing Page 28

27 TLS 1.3 Coming to you soon! Coming up No more RSA! Tomcat: as minimum since: , onwards IIS 10 (Schannel) on Windows Server 2016 not yet available Java 11- the first release officially implementing TLS 1.3 Firefox since v57 Chrome since v63 Other browsers not yet Page 29

28 Vulnerability testing and config tools Online, requires Internet connection: Any Web server: Offline Config: IIS: Page 30

29 Obtaining state-of-the-art encryption information testing tools, server rating, cipher collections Oracle JSSE reference guide: supported protocols, algorithms and key sizes for your JAVA version Tools to test the actually used cipher free TLS signed certificates Latest OpenSSL versions (includes tools to test CURL TLS) Page 31

30 Thank you.

31 October 2018 Your name/company Page 33