Unit 3: Security of E - Commerce Introduction, Security threats and solutions, Techniques and solutions for e- Commerce security, Message

Security: , Methods of encryption, Fast Cryptography, Certificate authority, Enterprise authentication using digital certificate, few security standards for the Internet, Shielding the network using Firewall, Role of Role of virtual private network (VPN), Network security

UNIT-3 Basic Security Concerns

For all the advantages of e-commerce, the major stumbling block is security threats. What is e-commerce security? People using the internet for commercial transactions always remain at risk of their confidential information such as passwords, and credit card details stolen and their cash siphoned off, or their identity hijacked to undertake criminal activities. Hackers use various techniques such as spear phishing attacks, click jacking, brute force attacks and more to extract personal user information for their nefarious ends.

Network security
There is no denying security threats to e-Commerce Web sites are on the increase. The question arises as to why e-commerce sites are prone to security risks. Is it because the e-Commerce software is designed without adequate care for security factors or is the number of cyber criminals on the rise? Analysts claim that the tools necessary to perform an assault on the Internet is fairly easy. All that the cyber criminal or hacker needs is access to a computer and an Internet connection. The shoppers computer, the network connection between the shopper and website server, website server and software vendor, are all easily identifiable, making the cyber criminal's task easy. If an attacker performs theft on the Internet the attacker can easily make escape without leaving any identity, and if the attackers are experts, even the source of the attack will remain untraceable. The underlying reason for such attacks is vulnerabilities in software and hardware. Software and hardware vendors, in their quest to ensure that their products are easy to install, ship products with security features disabled. Enabling security features requires some technical skills and the average user seldom attempt to enable the security features. Moreover, very often enabling the security features may impose restrictions that restrict functionality or slow down the system. Users remain reluctant to make such sacrifices, and this opens the gateway for attackers.

Ecommerce Threats & Solutions

eCommerce has forever revolutionized the way in which business is executed. Retail has now a long way through the days of physical transactions that were time consuming and prone to errors. Having said that, eCommerce has unavoidably invited its share of trouble makers. As much as eCommerce simplifies transactions, it can be occasionally plagued by serious concerns that jeopardize its security like a medium of exchanging money and info. Big threats to present day eCommerce involve

Breach of Security: Money Thefts eCommerce companies are about transactions, and transactions are really largely driven by money. This attracts hackers, crackers and everyone with the knowledge of exploiting loopholes in a procedure. Once a kink within the armor is discovered, they feed the technique(and users) with a lot of bits of dubious data to extract confidential info(phishing). This can be particularly dangerous as the information extracted may be that of credit score card numbers, security passwords, transaction details etc. Also, Payment gateways are vulnerable to interception by unethical users. Cleverly crafted strategies can sift an element or the entire amount being transferred through the user on the on the web vendor. Identification thefts Hackers often acquire entry to sensitive data like consumer accounts, consumer details, addresses, confidential personal information and facts etc. It really is a significant threat in view with the privileges a single can avail using a false identification. For instance, one can effortlessly login to an on the internet shopping mart under a stolen identification and make purchases worth thousands of dollars. He/she can then have the order delivered to an address other than the 1 listed around the records. A single can easily see how those orders could be received from the impostor without arousing suspicion. While the fraudsters gains, the original account holder continues to pay the price until the offender is nabbed. Threats to the system Viruses, worms, Trojans are very deceptive methods of stealing info. Unless of course a sound virus-protection strategy is used from the eCommere Solutions firm, these malicious agents can compromise the credibility of all eCommerce web solution providers. Often planted by individuals for reasons known very best to them alone, viruses breed within the systems and multiply at astonishing speeds. Unchecked, they will potentially cripple the entire process. Solutions There is but one solution to all issues that at times dent the security of eCommerce services. Strict vigil on malicious intruders. Easier said than executed? So is each preventive measure. On the other hand, with on the internet transactions, progress in security has been overwhelming. Authentication

Most notable are the advances in identification and elimination of non-genuine users. Ecommerce service designers now use multi-level identification protocols like security questions, encrypted passwords(Encryption), biometrics and others to confirm the identity of their shoppers. These steps have found wide favor all around due to their effectiveness in weeding out unwelcome access. Intrusion Check The issue of tackling viruses and their like has also seen rapid development with anti-virus vendors releasing strong anti-viruses. These are developed by expert programmers who are a notch above the hackers and crackers themselves. Firewalls are one other common way of implementing security measures. These programs restrict access to and through the procedure to pre-checked users/access points. Educating Users eCommerce is run primarily by users. Thus, eCommerce service providers have also turned to educating users about safe practices that make the entire operation trouble free. Recent issues like phishing have been tackled to a good extent by informing genuine users from the perils of publishing their confidential information and facts to unauthorized details seekers.

How encryption works?

When we use the Internet, we're not always just clicking around and passively taking in information, such as reading news articles or blog posts -- a great deal of our time online involves sending others our own information. Ordering something over the Internet, whether it's a book, a CD or anything else from an online vendor, or signing up for an online account, requires entering in a good deal of sensitive personal information. A typical transaction might include not only our names, e-mail addresses and physical address and phone number, but also passwords and personal sidentification numbers (PINs). The incredible growth of the Internet has excited businesses and consumers alike with its promise of changing the way we live and work. It's extremely easy to buy and sell goods all over the world while sitting in front of a laptop. But security is a major concern on the Internet, especially when you're using it to send sensitive information between parties. Let's face it, there's a whole lot of information that we don't want other people to see, such as:

Credit-card information Social Security numbers Private correspondence Personal details Sensitive company information Bank-account information

on computers and over the Internet by a variety of methods. A simple but straightforward security method is to only keep sensitive information on removable storage media like portable flash memory drives or external hard drives. But the most popular forms of security all rely on encryption, the process of encoding information in such a way that only the person (or computer) with the key can decode it. In this article, you will learn about encryption and authentication. You will also learn about public-key and symmetric-key systems, as well as hash algorithms.

here are three basic encryptionmethods: hashing, symmetric cryptography, and asymmetric cryptography. Each of these encryptionmethods have their own uses, advantages, and disadvantages. All three of these encryptionmethods use cryptography, or the science of scrambling data.

Methods of encryption
Cryptography is used to change readable text, called plaintext, into an unreadable secret format, called ciphertext, using a process called encryption. Encrypting data provides additional benefits besides protecting the confidentiality of data. Other benefits include ensuring that messages have not been altered during transit and verifying the identity of the message sender. All these benefits can be realized by using basic encryptionmethods. The first encryption method, called hashing, creates a unique fixed length signature of a group of data. Hashes are created with an algorithm, or hash function, and are used to compare sets of data. Since a hash is unique to a specific message, any changes to that message would result in a different hash, thereby alerting a user to potential tampering. A key difference between a hash and the other two encryptionmethods is that once the data is encrypted, the process cannot be reversed or deciphered. This means that even if a potential attacker were able to obtain a hash, he would not be able to use a decryption method to discover the contents of the original message. Some common hashing algorithms are Message Digest 5 (MD5) and Secure Hashing Algorithm (SHA). AdChoices High-performance crypto tools Fast, secure and inc. source code www.cryptomathic.com/primeink Take Saicra GLME From New Zealand Offered Competitive Prices In Having Knee Arthritis? India www.saicra.co.nz/india Free Diabetic Recipes > Breakfast, Lunch - Snack - Dinner - Dessert. Diabetic Diet & Meals www.diabetesinfocenter.org Eat Breakfast. Special K is a Low Fat Breakfast. Weight Management Tip: www.specialk.co.in Weight loss Lose weight, look good, feel great.Naturally! Cryptographic Toolkits

Kit@Rs.2999/-

www.health-total.com/

Symmetric cryptography, which is also called private-key cryptography, is the second encryption method. The term "private key" comes from the fact that the key used to encrypt and decrypt data must remain secure because anyone with access to it can read the coded messages. This encryption method can be categorized as either a stream cipher or a block cipher, depending upon the amount of data being encrypted or decrypted at a time. A stream cipher encrypts data one character at a time while a block cipher processes fixed chunks of data. Common symmetric encryption algorithms include Data Encryption Standard (DES), Advanced Encryption Standard (AES), International Data Encryption Algorithm (IDEA), and Blowfish. Asymmetric, or public key, cryptography is the last encryption method. This type of cryptography uses two keys, a private key and a public key, to perform encryption and decryption. The use of two keys overcomes a major weakness in symmetric key cryptography in that a single key does not need to be securely managed among multiple users. In asymmetric cryptography, a public key is freely available to everyone while the private key remains with receiver of ciphertext to decrypt messages. Algorithms that use public key cryptography include RSA and Diffie-Hellman.

Certificate authority
In cryptography, a certificate authority, or certification authority, (CA) is an entity that issues digital certificates. The digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified. In this model of trust relationships, a CA is a trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate. CAs are characteristic of many public key infrastructure (PKI) schemes. Commercial CAs charge to issue certificates that will automatically be trusted by most web browsers (Mozilla maintains a list of at least 36 trusted root CAs, though multiple commercial CAs or their resellers may share the same trusted root).[1] The number of web browsers and other devices and applications that trust a particular certificate authority is referred to as ubiquity. Aside from commercial CAs, some providers issue digital certificates to the public at no cost. Large institutions or government entities may have their own CAs. Domain Validation The commercial CAs that issue the bulk of certificates that clients trust for email servers and public HTTPS servers typically use a technique called "domain validation" to authenticate the recipient of the certificate. Domain validation involves sending an email containing an authentication token or link, to an email address that is known to be administratively responsible for the domain. This could be the technical contact email address listed in the domain's WHOIS

entry, or an administrative email like postmaster@ or root@ the domain. The theory behind domain validation is that only the legitimate owner of a domain would be able to read emails sent to these administrative addresses. Domain validation suffers from certain structural security limitations. In particular, it is always vulnerable to attacks that allow an adversary to observe the domain validation emails that CAs send. These can include attacks against the DNS, TCP, or BGP protocols (which lack the cryptographic protections of TLS/SSL), or the compromise of routers. Such attacks are possible either on the network near a CA, or near the victim domain itself. Some Certificate Authorities offer Extended Validation (EV) certificates as a more rigorous alternative to domain validated certificates. One limitation of EV as solution to the weaknesses of domain validation is that attackers could still obtain a domain validated certificate for the victim domain, and deploy it during an attack; if that occurred, the only difference observable to the victim user would be a blue HTTPS address bar rather than a green one. Few users would be likely to recognise this difference as indicative of an attack being in progress. Domain validation implementations have also sometimes been a source of security vulnerabilities. In one instance, security researchers showed that attackers could obtain certificates for webmail sites because a CA was willing to use an email address like SSLCertificates@domain.com for domain.com, but not all webmail systems had reserved the "SSLCertificates" username to prevent attackers from registering it [1].

Issuing a certificate
This article may be confusing or unclear to readers. Please help clarify the article; suggestions may be found on the talk page. (February 2009) A CA issues digital certificates that contain a public key and the identity of the owner. The matching private key is not made available publicly, but kept secret by the end user who generated the key pair. The certificate is also a confirmation or validation by the CA that the public key contained in the certificate belongs to the person, organization, server or other entity noted in the certificate. A CA's obligation in such schemes is to verify an applicant's credentials, so that users and relying parties can trust the information in the CA's certificates. CAs use a variety of standards and tests to do so. In essence, the Certificate Authority is responsible for saying "yes, this person is who they say they are, and we, the CA, verify that". If the user trusts the CA and can verify the CA's signature, then he can also verify that a certain public key does indeed belong to whoever is identified in the certificate.

Example
Public-key cryptography can be used to encrypt data communicated between two parties. This can typically happen when a user logs on to any site that implements the HTTP Secure protocol. In this example let us suppose that the user logs on to his bank's homepage www.bank.example to do online banking. When the user opens www.bank.example homepage, he receives a public

key along with all the data that his web-browser displays. When the user enters some information to the bank's page and submits the page (sends the information back to the bank) then the data the user has entered to the page will be encrypted by his web browser using the public key that was issued by www.bank.example. The key that can be used to decrypt the information is called the private key and it is only known to the bank. Therefore, even if someone can access the (encrypted) data that was communicated from the user to www.bank.example, the (unencrypted) data that the user has entered can only be decrypted by the bank, as only the bank knows the private key. This mechanism is only safe if the user can be sure that it is the bank that he sees in his web browser. If the user types in www.bank.example, but his communication is hi-jacked and a fake web-site (that pretends to be the bank web-site) sends the page information back to the user's browser, the fake web-page can send a fake public key to the user. The user will fill the form with his personal data and will submit the page which will be encrypted by the fake public key. The fake web-page will get access to the user's data since the fake web-page owns the fake private key. A certificate authority is an organization that stores public keys and their owners and every party in a communication trusts this organization. When the user's web browser receives the public key from www.bank.example it can contact the certificate authority to ask whether the public key does really belong to www.bank.example. Since www.bank.example uses a public key that the certification authority certifies, a fake www.bank.example can only use the same public key. Since the fake www.bank.example does not know the corresponding private key, it cannot decrypt the user's answer.

Enterprise authentication using digital certificate

Introduction Web servers typically use digital certificates for server authentication to Web clients using HTTPS (instead of HTTP protocol) to access the applications running on the server. Client authentication, however, is not often enforced using digital certificates; more common is the situation where the client is authenticated using elements such as a username and password. From the server's perspective, either authentication method is just as good, but authentication using username and password over HTTPS is still potentialy vulnerable due to lost, stolen, or otherwise compromised passwords. Client authentication using digital certificates can help overcome the problem of compromised credentials and give you a better sense of security about an application. This article describes the requirements for performing client authentication with digital certificates, and for making authentication and authorization decisions in Web applications deployed in IBM WebSphere Application Server Community Edition. This article highlights the private-key and certificate management functionality provided by the administrative console, and presents examples of Web applications that illustrate declarative and programmatic Web application security with client authentication using digital certificates.

This article requires WebSphere Application Server Community Edition Version 1.0.1 or later. Before you continue: This article was written for WebSphere Application Server Community Edition V1.0.1, which was the current version at the time the article was published. Some of the information in this article may not be applicable to later versions. To follow along with this article, be sure to use the product version on which this article is based. If you wish, you can download the current version of WebSphere Application Server Community Edition, or you can download an earlier version by visiting the product archive page. About digital certificates The most common use of a digital certificate is to verify that a user sending a message is who they claim to be, and to provide the receiver with the means to encode a reply. This feature is used for Web server and client authentication over HTTPS protocol, which is based on SSL. An entity wishing to send an encrypted message creates a public-private keypair and applies for a digital certificate from a Certificate Authority (CA). The CA issues an encrypted digital certificate containing the applicant's public key and a variety of other identification information. The CA makes its own public key readily available through print publicity. The most widely used standard for digital certificates is X.509. Using the administrative console The administrative console provides a convenient, user-friendly way to administer many aspects of WebSphere Application Server Community Edition (hereafter referred to as Community Edition). A work in progress that will continue to evolve over time, the admin console provides several portlets to perform a variety of administration tasks, such as the KeyStore, Web Server, Applications, and Security Realms portlets, which we will refer to throughout this article. The admin console also provides portlets that let an administrator view and monitor the status of the server, such as the Information, JVM, and DB Info portlets. Once Community Edition is started, you can access the admin console at http://localhost:8080/console. The default login is system with a password of manager. Key Store portlet The Key Store portlet in the administrative console operates on a JKS type Java keystore file preconfigured in Community Edition to point to the var/security/keystore file under server base directory. This portlet enables you to:

Enable administrative security automatically during installation. View the keystore contents. Generate RSA keypair (of key sizes 512, 1024 and 2048 bits). Generate Certificate Signing Requests (CSR). Import trusted certificates. Delete trusted certificates. Import CA reply. Delete private-keys.

These operations are an integral part of key management. (Community Edition users do not require key management tools like keytool.) The private keys and trusted certificates in the keystore can be used to configure HTTPS listeners for a Web container. We will use the KeyStore portlet in this article to:

Delete an existing keypair. Generate a new keypair. Generate a CSR. Import a trusted certificate. Import CA reply.

To launch KeyStore portlet in Community Edition, select the Keystore link under the Security heading in the Console Navigation section (Figure 1). To view details of any private-key or trusted certificate entry, click on the view link provided against that alias and the KeyStore portlet will display the entry details. Figure 1. Administrative console: KeyStore portlet

Web Server portlet The Web Server portlet enables an administrator to start/stop/delete various network listeners that are available for the Web container. It also lets you add new HTTP, HTTPS, and AJP network listeners. We will use the Web Server portlet in this article to:

Add a new HTTPS listener. Stop and start an existing network listener.

To launch the Web Server portlet, select the Web Server link under the Server heading in the Console Navigation section (Figure 1). Security Realms portlet The Security Realms portlet enables an administrator to add a new security realm and edit existing security realms. The portlet also has a usage link that provides information on how applications can be configured to authenticate against the security realm. We will use the Security Realms portlet in this article to add a new Certificate Properties File Realm. Launch the Security Realms portlet by clicking the Security Realms link under the Security heading in the Console Navigation section (Figure 1). Applications portlets There are multiple Applications portlets that let an administrator deploy new Web applications, EJB components, J2EE applications, application clients, J2EE connectors, and so on, to Community Edition. The portlets also enable starting, stopping, and uninstalling existing applications, connectors, and more. We will use the Deploy New Applications portlet to deploy our sample applications. To launch this portlet, select the Deploy New link under the Applications heading in the Console Navigation section (Figure 1). Back to top Setting up the keystore The default keystore (<base-dir>/var/security/keystore) that is distributed with Community Edition contains a keypair with alias "geronimo," and a trusted certificate with the alias "geronimoca". Unless you generate a new keypair after server installation and delete this default keypair, you will be using a private-key that is used by several other Community Edition server installations. In this section, we describe the process of setting up your keystore using the KeyStore portlet, so that it can be used to configure HTTPS listeners. Generate keypair To generate a new keypair, launch the KeyStore portlet and click on the generate keypair link (Figure 1). This will display a form where details can be entered for the keypair to be generated (Figure 2). Definitions of key configuration fields follow.

Figure 2. Generate key pair

Alias: Name used to identify this keypair in the keystore. This should be different from the alias of existing entries in the keystore. In our example, we use "mybizzzkeys" as the alias, which is different from the two existing aliases "geronimo" and "geronimoca". Key Algorithm: The private key algorithm to be used to generate the keypair. The administrative console supports only "RSA". Key Size: Length in bits of the modulus of RSA keypair. The higher the key size, more secure is the keypair. The administrative console supports 512, 1024, and 2048 key sizes. In our example, we use a key size of 1024. (See Resources for key size recommendations for RSA keys. Signature Algorithm: The signature algorithm to be used to sign the self-signed certificate generated as part of "generate keypair" exercise. The administrative console supports MD2withRSA, MD5withRSA, and SHA1withRSA signature algorithms. In our example, we use MD5withRSA. Validity: Indicates the validity of the keypair in number of days. In our example, we use a validity value of 365. Common Name (CN): The DNS name of the Web server hosting your Web application(s) that wants to authenticate the server to Web clients. For example, if the application is to be hosted on www.mybizzz.com, use the same as the common name so that clients will use http://www.mybizzz.com or https://www.mybizzz.com to access the application. In our example, we use "localhost" as the common name.

Organizational Unit (OU)/Organizational Name (O)/Locality (L)/State (ST): Complete these fields to reflect the identity of the requestor. Country (C): The two-letter ISO 3166 country code of the requestor's country. In our example, we use IN, which is the country code for India.

Upon submitting the form, the KeyStore portlet generates a new RSA keypair, a self-signed certificate, and adds the keypair to the keystore. To view the details of the newly added entry, click on the view link (Figure 1) provided against the alias (here, mybizzzkeys). Figure 3 shows the details of this newly generated keypair.

Figure 3. Private key details

Generate CSR To obtain a digital certificate from a Certification Authority (CA), a Certificate Signing Request (CSR) needs to be generated from the keypair and sent to the CA. To generate a CSR for any private-key entry, first view the entry details in the KeyStore portlet (Figure 3). After you select the generate CSR link, the KeyStore portlet will generate a PKCS10 Certification Request and display it in a text area so that the text can be copied and pasted into a text file. Listing 1 shows the CSR generated in our example. Import CA reply Upon receiving the CSR, the CA will verify the validity of the information in the CSR and issue a certificate. The reply from CA is usually in a PKCS7 encoded text format containing the client's certificate signed by the CA, and may contain additional certificates chaining up to a

Root CA. For our purposes, the CA reply (Listing 2) from "My Own Root CA", which is a homegrown CA, contains a single certificate.

Listing 2. CA Reply from "My Own Root CA" The CA reply given here is for the certificate request from our example only. The CA reply for any certificate request that you might generate while following along with this article will be different. To import the CA reply shown in Listing 2, overwrite "var/security/keystore" with the keystore.new file provided in the download file, then restart the Community Edition server at this point in the article. To import CA reply: 1. View the entry details of "mybizzzkeys" in the KeyStore portlet (Figure 3). 2. Click on the import CA reply link and paste the contents of the CA reply text file into the text area under the PKCS7 Certificate Reply heading. 3. Click the Save button. The keystore is now ready to be used by Community Edition for Web server authentication using the newly obtained certificate.

Figure 4. Imported CA reply

Delete default private-key The default keystore contains a private-key with an alias of "geronimo". This is required for starting the default HTTPS listener. Once a new keypair is generated using the KeyStore portlet, the default private-key is no longer required. Since there is no provision to specify the alias of the private-key in the keystore to be used by HTTPS listeners, the default private-key entry should be removed from the keystore. To remove the default private-key entry: 1. Click on the view link (Figure 1) provided against alias "geronimo". 2. Click on the Delete Entry link (Figure 3) and confirm the entry deletion. 3. Upon confirmation, the default private-key entry is deleted from the keystore. The keystore now has a single private-key entry with alias "mybizzzkeys". Any HTTPS listeners using the var/security/keystore file will now use this private-key for server authentication. Import CA certificate as trusted certificate Importing a CA certificate into the keystore as a trusted certificate is required to enable client authentication over HTTPS. Upon importing a CA certificate as a trusted certificate, all certificates issued by that CA will be accepted for client authentication. In our sample applications, we use client certificates issued by "My Own Root CA". To make sure that the HTTPS listener accepts certificates issued by this CA, the CA's certificate (Listing 3) needs to be imported into the keystore as a trusted certificate. To import a trusted certificate: 1. Click on import trusted certificate in the KeyStore portlet (Figure 1). 2. Select the file or enter the filename containing the CA's certificate and click on the View Certificate button. (In our example, the CA certificate is in a text file, myownrootcacert.txt, provided in the download file.) 3. Enter an alias for this trusted certificate and click on the Import button (Figure 5) to complete the import. (The alias used should be different from the aliases of existing entries in the keystore.)

Figure 5. "My Own Root CA" certificate details

HTTPS listener with client authentication The default HTTPS listener on port 8443 is not enabled for client authentication. This HTTPS listener is configured to use var/security/keystore. After the updates to keystore have been applied through the KeyStore portlet in the previous section, this HTTPS listener will use the newly added private-key entry for server authentication. To verify this, stop and start the default HTTPS listener through the Web server portlet and access the URL https://localhost:8443/. (Before accessing this URL, you must install the CA certificate into your Web browser to avoid any warning messages.) When the page has loaded, double-click on the lock icon provided on the browser taskbar and view the certificate details by clicking on the view button (Figure 6). Verify that the certificate is indeed issued by "My Own Root CA". In our example, we used the Mozilla Firefox Web browser.

Figure 6. Server certificate details viewed in the browser

Add HTTPS listener with client authentication An HTTPS listener enabled for client authentication is required to configure Web applications for client authentication using digital certificates. In this section, we will look at how a new HTTPS listener can be added using the Web Server portlet, and the significance of various parameters. To add a new HTTPS Listener: 1. Launch the Web Server portlet and select the Add new HTTPS Listener for Tomcat link. 2. Enter values for all applicable parameters and click the Save button (Figure 7). This will add and start a new HTTPS listener. Descriptions of key parameters follow.

Figure 7. HTTPS Listener parameters

Host: Host name or IP to which the port will bind. We use 0.0.0.0 in our example. Port: Network port to bind. In our example, we use 443, which is the default port for HTTPS. Keystore File: File that holds the keystore. The KeyStore portlet is preconfigured to point to var/security/keystore under the Community Edition install directory. The keypair generated earlier in this article is added to this file by the KeyStore portlet, and so, we will be use var/security/keystore in this field.

Keystore Password: Password used to access the keystore file and the private-key entry. The KeyStore portlet is configured to use the password secret. Keystore Type: The keystore type of the Keystore File field entry. The keystore type of var/security/keystore is "JKS". Truststore File: The file that holds the truststore. In our example, the trusted certificates are added to var/security/keystore, which itself will act as truststore. Therefore, we will be use var/security/keystore for this field. Truststore Password: Password used to verify the Truststore File field, which in our example is the password of var/security/keystore, which is secret. Truststore Type: The keystore type of the Truststore File field entry. In our example, it is "JKS." HTTPS Algorithm: The HTTPS Algorithm provider. This should typically be set to match the JVM vendor. Using "JVM Default" for this field will not require reconfiguring the HTTPS listener when the server is run on a different JVM than the value selected here. In our example, we use "JVM Default" for this parameter. HTTPS Protocol: This should typically be set to TLS, though some JVMs do not work properly with popular browsers unless it is changed to SSL. In our example, we use "SSL" for this parameter. Client Auth Required: In our example, we set this field to require client authentication. If this is field is set, then clients connecting through this connector must supply a valid client certificate. The validity is checked using the CA certificates stored in the first of the following to be found: 1. The trust store configured above. 2. A keystore file specified by the javax.net.ssl.trustStore system property. 3. java-home/lib/security/jssecacerts. 4. java-home/lib/security/cacerts. Since we have configured a truststore, only the certificates issued by those CAs in the truststore will be accepted for client authentication.

Verify HTTPS listener with client authentication To verify that the newly added HTTPS listener is functional, access the URL https://localhost/. Since no client certificates issued by any of the trusted CAs are available in the browser, this results in an error and the Web page cannot be accessed. Now, import a private-key and client certificate issued by "My Own Root CA" provided in the file webclient01.p12 into the Web browser, and then access the URL https://localhost/ again. This time, since the browser has a client certificate issued by one of the CAs in truststore, the browser displays a dialog (Figure 8) that lets you choose a certificate for authenticating to the Web server. After you select the client certificate, the server authenticates the client and the Web page is now accessible.

Figure 8. Selecting client certificate for authentication

Back to top Adding a security realm for declarative security Once the Web server has been configured with an HTTPS listener with client authentication, a certificate properties file realm can be added; Web applications can then be configured to authenticate against this realm. This section describes how such a security realm can be added to Community Edition. Properties files A certificate properties file realm is configured using two properties file parameters: users file and groups file. Samples are shown below of a users file (Listing 4) and a groups file (Listing 5). These files are based on the client certificates provided in webclient01.p12, webclient02.p12,

webclient11.p12 and webclient12.p12 (available in the download file), which should be imported into a Web browser so you can use the sample applications.

NTERNET SECURITY
As businesses move to take advantage of collaborative computing and electronic commerce on the Internet, data security has been a growing area of interest. Although there are undoubtedly more data security related products and services available today than ever before there are also more security related incidents each year. The rapid growth of the Internet and the constant introduction of new technologies, while creating new opportunities for businesses, also create new opportunities for hackers. For the Internet, security was an afterthought. It is often said that the Internet was not designed with security in mind. The Internet is composed of many different technologies and is inherently open. Openness was one of the design goals behind basic Internet technologies like TCP/IP, which is a hardware and network independent protocol. While this enables any computer or network to be connected to the Internet it also makes it easy for hackers to attempt break-ins while at the same time making them hard to trace. The rise in the complexity and diversity of the Internet has caused the need for security expertise to exceed the supply. As a result, inexperienced technical staff often implement security measures that are vulnerable to hackers. On the Internet, hackers don't always need to break in to access confidential information since much of the traffic on the Internet is not encrypted. Encryption has been a growing area of activity in the past few years and today intranets, extranets, and email all involve some type of security. Developing Internet standards have come to drive security technology. The purpose of this article is to familiarize you with the basic Internet security technologies. Over the next few months we'll look at Domino's historical security model and contrast this with the emerging Internet standards-bases security technologies that will be integrated into Domino 5.0 and beyond.

WHAT IS NETWORK SECURITY?

The networks are computer networks, both public and private, that are used every day to conduct transactions and communications among businesses, government agencies and individuals. The networks are comprised of "nodes", which are "client" terminals (individual user PCs) and one or more "servers" and/or "host" computers. They are linked by communication systems, some of which might be private, such as within a company, and others which might be open to public access. The obvious example of a network system that is open to public access is the Internet, but many private networks also utilize publicly-accessible communications. Today, most companies' host computers can be accessed by their employees whether in their offices over a private

communications network, or from their homes or hotel rooms while on the road through normal telephone lines. Network security involves all activities that organizations, enterprises, and institutions undertake to protect the value and ongoing usability of assets and the integrity and continuity of operations. An effective network security strategy requires identifying threats and then choosing the most effective set of tools to combat them. Threats to network security include: Viruses : Computer programs written by devious programmers and designed to replicate themselves and infect computers when triggered by a specific event Trojan horse programs : Delivery vehicles for destructive code, which appear to be harmless or useful software programs such as games Vandals : Software applications or applets that cause destruction Attacks : Including reconnaissance attacks (information-gathering activities to collect data that is later used to compromise networks); access attacks (which exploit network vulnerabilities in order to gain entry to e-mail, databases, or the corporate network); and denial-of-service attacks (which prevent access to part or all of a computer system) Data interception : Involves eavesdropping on communications or altering data packets being transmitted Social engineering : Obtaining confidential network security information through nontechnical means, such as posing as a technical support person and asking for people's passwords Network security tools include: Antivirus software packages : These packages counter most virus threats if regularly updated and correctly maintained. Secure network infrastructure : Switches and routers have hardware and software features that support secure connectivity, perimeter security, intrusion protection, identity services, and security management. Dedicated network security hardware and software-Tools such as firewalls and intrusion detection systems provide protection for all areas of the network and enable secure connections. Virtual private networks : These networks provide access control and data encryption between two different computers on a network. This allows remote workers to connect to the network without the risk of a hacker or thief intercepting data. Identity services : These services help to identify users and control their activities and transactions on the network. Services include passwords, digital certificates, and digital authentication keys. Encryption : Encryption ensures that messages cannot be intercepted or read by anyone other than the authorized recipient. Security management : This is the glue that holds together the other building blocks of a strong security solution. None of these approaches alone will be sufficient to protect a network, but when they are layered together, they can be highly effective in keeping a network safe from attacks and other threats to security. In addition, well-thought-out corporate policies are critical to determine and control access to various parts of the network.