The Courts Informatics Division is maintaining Causelists of 18 High Courts and 10 Benches on Internet for providing easy and timely access to the advocates and litigant public. Causelists are scheduling of cases to be heard by the courts on the following day. It is a must for every High Court to generate causelists by the evening of the day before. Size of each High Courts’ Causelist vary from hundred to two hundred printed pages. Ever since the ‘Causelists on Internet’ has been made available, the popularity of Causelist site has been growing regularly. The site receives about 25,000 hits per day. This is very sought after application by the advocates The Causelists are generated from NIC Servers installed in each High Court using the List of Business Information System (LOBIS) Software. As per the usual practice, once a Causelist is generated from the computer system, the High Court either cuts stencils for each page of the causelist and cyclostyle to generate thousands of copies to distribute among the advocates or sends a printed copy for photo-offset printers. As the generation and distribution of causelist copies usually takes four to five hours, the advocates receive printed copies of the causelists only late night at their offices/residences. With the availability of causelists on Internet, the advocates are in a position to view and download their High Court’s Causelist as soon as they are generated by the LOBIS Software i.e. about 6.00 P.M. everyday.

Procedure

As a file of Causelist of each High Court is about 5 to 7 MB in size , NIC High Court Computer Cells send the ASCII file of the causelist through ‘ftp’ to the server at the NIC-Headquarters. After the files are transeferred through FTP, they ‘telnet’ to the server to run the software script which converts the ASCII file into a structured format and uploads on the web. The process of ftp and telnet to run the script usually take less than 3 to 4 minutes depending on the network speed. As the ASCII files are to be sent through ftp and telnet to the server, the server side ftp port and telnet port have to be opened, thus making it a soft target to the potential hackers. Unless these two ports are opened throughout, no High Court can upload their data file and run the script. As the High Courts generate causelists at their own convenience without any fixed time frame, it is not possible for anyone at the server level to upload the causelist by a special service. In order to sort out the potential problem of getting hacked, the COURTIS Division has effectively employed Secure Sockets Layer (SSL) for this web-enabled application. The SSL, which has been in use by many of the Banks for their on-line financial transactions, is a well proven security technology.

Technical Brief

SSL server certificates satisfy the need for confidentiality, integrity, authentication, and nonrepudiation. Basically SSL is used to encrypt and decrypt messages sent between the browser and the server. By encrypting the data, it is protected from being read while they are transferred across the Internet. SSL encrypts the data from the browser, then sends it to the server. When the server side SSL receives the message, it decrypts it and verifies that it came from the correct sender (authentication). SSL Software needs to be installed on both the browser and server. Usually most of the recent browsers support SSL. The SSL comes in 40 bit and 128 bit encryption.

The process begins by establishing an SSL "handshake" — allowing the server to authenticate itself to the browser user, and then permitting the server and browser to cooperate in the creation of the symmetric keys used for encryption, decryption, and tamper detection:

  1. A customer contacts a site and accesses a secured URL: a page secured by a Server ID (indicated by a URL that begins with "https:" instead of just "http:" or by a message from the browser).
  1. The customer’s browser automatically sends the server, the browser’s SSL version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL.
  1. The server responds, automatically sending the customer’s browser, the site’s digital certificate, along with the server’s SSL version number, cipher settings, etc.
  1. The customer’s browser examines the information contained in the server’s certificate, and verifies that:

(a.) The server certificate is valid and has a valid date. (b.) The CA that has issued the server been signed by a trusted CA whose certificate is built into the browser (c.) The issuing CA’s public key, built into the browser, validates the issuer’s digital signature (d.) The domain name specified by the server certificate matches the server’s actual domain name If the server cannot be authenticated, the user is warned that an encrypted, authenticated connection cannot be established.

  1. If the server can be successfully authenticated, the customer’s Web browser generates a unique "session key" to encrypt all communications with the site using asymmetric encryption.
  1. The user’s browser encrypts the session key itself with the site’s public key so that only the site can read the session key, and sends it to the server.
  1. The server decrypts the session key using its own private key.
  1. The browser sends a message to the server informing it that future messages from the client will be encrypted with the session key.
  1. The server then sends a message to the client informing it that future messages from the server will be encrypted with the session key.
  1. An SSL-secured session is now established. SSL then uses symmetric encryption, (which is much faster than asymmetric PKI encryption) to encrypt and decrypt messages within the SSL-secured "pipeline."
  1. Once the session is complete, the session key is eliminated.

It all takes only seconds and requires no action by the user.

At present the COURTIS Division is using a Digital Certificate that is available for free for one year. The users of the High Courts, use the SSL facility by https://164.100..... Once authenticity of the user is confirmed by the server’s decryption mechanism, the user is allowed to ftp the files and run the script through a special module written in PHP. By a click of a button, the end user is able to send the file to the Server and run the script for up loading the data in a highly secured manner. SSL allows the Server to be brought under Firewall, thus providing full security for the Server from any potential hackers.