Internetteknologi 2 (ITNET2)

1. Internetteknologi 2 (ITNET2) Presentation 5: Security

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 ApplicationsJSP/Servlets

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. Declarative Security

25. Programmatic Security

26. Form-Based Authentication(Declarative Security)

27. Form-Based Authentication(Continued)

28. Form-Based Authentication(Continued)

29. Form-Based Authentication(Continued)

30. Form-Based Authentication(Continued)

31. Form-Based Authentication(Continued)

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. 1) Generating SSL Keystore Certificate • Run Java Keytool • Move resulting file to Tomacat Home keytool -genkey -alias tomcat -keyalg RSA -keystore tomcatkeystore.jks

34. 2) Configure Apache Tomcat • Edit <tomcat_home>\conf\server.xml • Uncomment the following Production servers operate standard at port 443 <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“ />

35. Unknown Certificate

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. Example: Step 1

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. Example: Step 2

40. Example: Step 3Create a Login Page <html> <head> <title>Login Page for Examples</title> <body bgcolor="white"> <form method="POST" action='<%= response.encodeURL("j_security_check") %>' > <table border="0" cellspacing="5"> <tr> <th align="right">Username:</th> <td align="left"><input type="text" name="j_username"></td> </tr> <tr> <th align="right">Password:</th> <td align="left"><input type="password" name="j_password"></td> </tr> <tr> <td align="right"><input type="submit" value="Log In"></td> <td align="left"><input type="reset"></td> </tr> </table> </form> </body> </html>

41. Example: Step 4Create a failed login page (error.jsp) <html> <head> <title>Error Page For Examples</title> </head> <body bgcolor="white"> Invalid username and/or password, please try <a href='<%= response.encodeURL("login.jsp") %>'>again</a>. </body> </html>

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. Example: Step 5

44. Example: Step 5 (continued)

45. Example: Step 6

46. Example: Step 6Result after Logging in SSL at port 8443 SSL at port 8443

47. Form-Based vs. BASICAuthentication

48. BASIC Authentication

49. BASIC Authentication(Continued)

50. Example