1. Presentation 5: Security Internetteknologi 2 (ITNET2)

2. Ingeniørhøjskolen i Århus Slide 2 Agenda –Plenum: your experience with security –Threats and Security Attacks –What is needed to provide secure solutions –Encryption and SSL –Security in J2EE Applications Declarative Security (Ex Configuration in XML files) “Semi-declarative Security” Programmatic Security (Your code and application) Examples are in J2EE (JSP/Servlets) but principles are the same on all server-side platforms

3. Ingeniørhøjskolen i Århus Slide 3 Experience with Security To establish a picture of your knowledge –What kind of security issues do you know of? –How may these be solved? –What experience do you have in using these?

4. Security Attacks

5. Ingeniørhøjskolen i Århus Slide 5 Motivation Many vital/secret data handled by distributed systems Loss of confidence: above effects may reduce confidence in systems. –And in the company (and the developer) who made the system! Legal issues – in DK there are strict rules for handling of personal data (Persondataloven) –Other legal issues – if you make a mistake … They will sue your ass off ;-)

6. Ingeniørhøjskolen i Århus Slide 6 Why are Distributed Systems insecure? Distributed components rely on messages sent and received from network Public Networks are insecure! –Anyone can listen and capture data packages –Try downloading a sniffer (http://www.ethereal.com/) Is a client (e.g. a browser) secure? Are users of calling clients really who they claim to be? Are the users allowed do all the possible actions?

7. Ingeniørhøjskolen i Århus Slide 7 Effects of Insecurity Confidential Data may be stolen, e.g.: –corporate plans –new product designs –medical/financial records (e.g. Access bills....) Data may be altered, e.g.: –finances made to seem better than they are –results of tests, e.g. on drugs, altered –examination results amended (up or down) –OR worse – a nuclear power plant cooling control gets turned off … or the new radar delivered from Terma hides North Korean fighter planes or rockets …

8. Ingeniørhøjskolen i Århus Slide 8 Threats Categorisation of attacks (and goals of attacks) that may be made on system Four main areas (from Emmerich/Colouris): –leakage: information leaving system –tampering: unauthorised information altering –resource stealing: illegal use of resources –vandalism: disturbing correct system operation Used to specify what forms of attack the system is proof, or secure, against

9. Ingeniørhøjskolen i Århus Slide 9 Methods of Attack Eavesdropping*: Obtaining message copies without authority (*to listen to a conversation without the speakers being aware of it) Masquerading: Using identity of another principle (eg user) without authority –Simply read the document, and steal the password Message tampering: Intercepting and altering messages (HTML/HTTP/SQL injection) Replaying: Storing messages and sending them later

10. Ingeniørhøjskolen i Århus Slide 10 Infiltration Launch of attack requires access to the system –Launched by legitimate users –Launched after obtaining passwords of known users Aka “social engineering” – actually quite easy ;) Subtle ways of infiltration: –Viruses –Worms –Trojan horses –Exploits (exploiting some known weakness)

11. Ingeniørhøjskolen i Århus Slide 11 What’s needed for secure requests 1? Separating public and private networks (firewalls) –Or Virtual Private Networks (VPN’s) –But many users will not be willing to download a VPN client Establishing security association between client & server (authentication/authenticity) via e.g. public keys, digital signature, others Deciding whether principal may perform this operation (access control) – username/password and/or digital signature matched w. ACL

12. Ingeniørhøjskolen i Århus Slide 12 What’s needed for secure requests 2? Making the principal accountable for having requested the operation (auditing) – tracking access of authenticated user Protecting request and response from eavesdropping in transit (encryption) via SSL Proving that you have delivered a particular service (non-repudiation) – tracking access of authenticated user

13. Ingeniørhøjskolen i Århus Slide 13 Desirable Properties Desirable properties: –confidentiality –integrity –authenticity –access control –auditing –non-repudiation (Repudiation is something like “a refusal by a government to acknowledge and honor a claim or obligation because it is considered to be invalid”) SSL/TLS Username/password or digital signature

14. Main Security Principle: Encryption by SSL

15. Ingeniørhøjskolen i Århus Slide 15 Introduction Cryptography: encode message data so that it can only be understood by intended recipient Romans used it in military communication Given knowledge of encryption algorithm, brute force attempt: try every possible decoding until valid message is produced Computers are good at this!

16. Ingeniørhøjskolen i Århus Slide 16 Encryption Encrypting data prevents unauthorised access and modification to the data (i.e. prevents eavesdropping and tampering) If encrypted data can only be decrypted with a matching key, this can be used to prove sender’s identity (i.e prevents masquerading) Likewise, it can be used to ensure that only intended recipients can use the data Two main ways: secret key & public key

17. Ingeniørhøjskolen i Århus Slide 17 Using Secret Keys (Symmetric) One key is used to both encrypt and decrypt data Must exchange keys through some secure, trusted, non-network based means –As a disk via snail mail, or build into executable Sender encodes message using function and sends, knowing that only the holder of key (the intended recipient) can use it. Recipient decodes message and knows that only sender could have generated it Message can be captured but is of no use

18. Ingeniørhøjskolen i Århus Slide 18 Public Keys (Asymmetric) Gives 'one-way' security Two keys generated, one used with decryption algorithm (private key) and one with encryption algorithm (public key) Generation of private key, given public key is computationally hard (hard to crack) Do not need secure key transmission mechanism for key distribution

19. Ingeniørhøjskolen i Århus Slide 19 Using Public Keys Recipient generates key pair Public key is published by trusted service Sender gets public key, and uses this to encode message Receiver decodes message with private key Replies can be encoded using sender’s public key (actually a second key) from the trusted distribution service Message can be captured but is of no use

20. Ingeniørhøjskolen i Århus Slide 20 Secure Socket Layer (SSL) Secure Transport between Browser and Web- Server –Solves the problem with thin clients – eg HTML transfers Also used for object-oriented middleware Based on RSA public key technology Client generates secret session key Client uses public key of server to encrypt session key and transmit it to the server Session key is used to encrypt any communication between client and server

21. Security in J2EE Applications JSP/Servlets

22. Ingeniørhøjskolen i Århus Slide 22 Two Main Methods Declarative Security (Container managed) –Security is handled by container –Easy to implement –Less flexible –FORM-based Authentication –BASIC Authentication Programmatic Security (Application managed) –Security is handled by programmer –Harder to implement –More flexible Both should use SSL encryption

23. Declarative Security

24. Ingeniørhøjskolen i Århus Slide 24 Declarative Security

25. Ingeniørhøjskolen i Århus Slide 25 Programmatic Security

26. Ingeniørhøjskolen i Århus Slide 26 Form-Based Authentication (Declarative Security)

27. Ingeniørhøjskolen i Århus Slide 27 Form-Based Authentication (Continued)

28. Ingeniørhøjskolen i Århus Slide 28 Form-Based Authentication (Continued)

29. Ingeniørhøjskolen i Århus Slide 29 Form-Based Authentication (Continued)

30. Ingeniørhøjskolen i Århus Slide 30 Form-Based Authentication (Continued)

31. Ingeniørhøjskolen i Århus Slide 31 Form-Based Authentication (Continued)

32. Ingeniørhøjskolen i Århus Slide 32 Enabling SSL Some servers have default SSL support Apache Tomcat must first be configured Two steps –1) Generate a private key (using Java Keytool) –2) Configure Apache Tomcat (or other Application Server)

33. Ingeniørhøjskolen i Århus Slide 33 1) Generating SSL Keystore Certificate Run Java Keytool Move resulting file to Tomacat Home keytool -genkey -alias tomcat -keyalg RSA -keystore tomcatkeystore.jks

34. Ingeniørhøjskolen i Århus Slide 34 2) Configure Apache Tomcat Edit \conf\server.xml Uncomment the following <Connector port="8443" maxThreads="150“ minSpareThreads="25" maxSpareThreads="75“ enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="C:/Program Files/ Apache Software Foundation/Tomcat 5.5/tomcatkeystore.jks" keystorePass="testtest“ /> Production servers operate standard at port 443

35. Ingeniørhøjskolen i Århus Slide 35 Unknown Certificate

36. Ingeniørhøjskolen i Århus Slide 36 Example: Form-Based Security Find example in Apache Tomcat: C:\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\jsp-examples\security\protected Must enable SSL for the Application Server at first !

37. Ingeniørhøjskolen i Århus Slide 37 Example: Step 1

38. Ingeniørhøjskolen i Århus Slide 38 Alternative Realms You may use other sources to obtain a list of users and passwords These are called ”Realms” Available Realms: –MemoryRealms (fetches from tomcat-users.xml) –JDBCRealm & DataSourceRealm (from a DB) –JNDIRealm (from a Java Naming and Directory Interface – including LDAP) –JAASRealm (for other sources, including Microsoft Active Direectory)

39. Ingeniørhøjskolen i Århus Slide 39 Example: Step 2

40. Ingeniørhøjskolen i Århus Slide 40 Example: Step 3 Create a Login Page Login Page for Examples ' > Username: Password:

41. Ingeniørhøjskolen i Århus Slide 41 Example: Step 4 Create a failed login page (error.jsp) Error Page For Examples Invalid username and/or password, please try '>again.

42. Ingeniørhøjskolen i Århus Slide 42 Example: Access Rules In the Apache Tomcat security example we only have one role for one mapping (index.jsp), and only using SSL (the CONFIDENTIAL setting). You may however make any combination of mappings you might like

43. Ingeniørhøjskolen i Århus Slide 43 Example: Step 5

44. Ingeniørhøjskolen i Århus Slide 44 Example: Step 5 (continued)

45. Ingeniørhøjskolen i Århus Slide 45 Example: Step 6

46. Ingeniørhøjskolen i Århus Slide 46 Example: Step 6 Result after Logging in SSL at port 8443 SSL at port 8443

47. Ingeniørhøjskolen i Århus Slide 47 Form-Based vs. BASIC Authentication

48. Ingeniørhøjskolen i Århus Slide 48 BASIC Authentication

49. Ingeniørhøjskolen i Århus Slide 49 BASIC Authentication (Continued)

50. Ingeniørhøjskolen i Århus Slide 50 Example

51. Ingeniørhøjskolen i Århus Slide 51 Extending Declarative Security Basic Declarative is ‘all or nothing’ Possible to get user data from security system From HTTPServletRequest –isUserInRole –getRemoteUser –getUserPrincipal You are logged in as remote user in session <% if (request.getUserPrincipal() != null) { %> Your user principal name is <%

52. Programmatic Security

53. Ingeniørhøjskolen i Århus Slide 53 Programmatic Security You may implement the security yourself Using session variables (or Cookies as Nordfalk) –You might use a ”User” or ”Login” object attached to the session Similar to Form-based authentification –But NOTHING is automated –Must invent own role system If you want to use SSL with Apache Tomcat Securing the Calender application Protected Area /cal/* CONFIDENTIAL Protecting the Apache Tomcat Calendar application

54. Ingeniørhøjskolen i Århus Slide 54 Checking for SSL –If programmer is uncertain of server SSL capabilities –request.getScheme (returns http or https) –requeset.isSecure (returns true or false) Quality of SSL encoding (number of bits) –request.getAttribute(“javax.servlet.request.key_size”); Looking up encryption algorithm –request.getAttribute(“javax.servlet.cipher_suite”); Redirecting if no SSL – or quality too low –respone.sendRedirect Only when administrator and programmers cannot work together

55. Ingeniørhøjskolen i Århus Slide 55 Benefits of Programmatic Security Advantages –Provides independence of server-specific components –More flexible than Declarative security –Permits custom security system (alternative to username / password) –No need for web.xml entries (depending on server ssl) Disadvantages –Must write own security framework –No way to protect e.g. an entire folder of JSP files, all files must contain security checks (or web.xml must be used to force all data through a Front Controller) –Tedious and error-prone work