We are the very first people ever at UB to be taking credit cards over the Internet. The security software was installed at the end of March, and tested for two weeks (including one week on the client-and-CGI end by me) before being thrown open for use. The system should still be regarded as provisional, and from time to time the server will be down. Here are some answers to questions you may have.
The security protocol is a standard "Apache" implementation of SSL, which originated with Netscape and is supported by all major browsers. The encryption is a 40-bit RSA implementation, the maximum currently certified for export from the U.S. (Yes, writing this page makes me an exporter:-). After loading the secure-registration page, you can view the "Page Info" to see more details about it. How secure is a 40-bit key?
First, your SSL-compliant browser has a public key, which it sends unencrypted to our server. Our server then encrypts the registration-form page and sends it to your browser, and also sends you its public key. Your browser then encrypts what you type and sends that to our server for decoding.
When you click "Submit", you activate a CGI script on our server that appends what you entered to two files that are accessible only by UB staff and myself. One file is in .db format, the other an ordinary text file. The script also sends e-mail to conference manager Bill Williams and myself, forwarding just your name, e-mail address, and anything you entered in the "Accessibility/Special Needs" field. Finally, it forwards you to a "Thanks!" page, and this implies that all processing is successfully completed.
The CGI script itself is world-readable, and this does not impinge on security. You can find and view it yourself easily enough. It is pretty primitive---it doesn't check your addition or flag you if you fail to enter a "required field". It follows the hardcopy brochure that we mailed except for the lack of a "credit-card signature" line---as of 1998 not everyone has personal digital signatures conforming to a single standard. I wrote the form and most of the CGI script---anyone with more time and Perl savvy is welcome to code improvements.
The link's header "https://" rather than "http://" informs your browser than it is about to access a secure document, and unless you've turned off all security warnings in your browser, you should get a message about this. What you shouldn't get is a later message saying "although the document...is secure, your transmission is insecure..." Such a message can have disparate causes---we had to make our "Thanks!" page itself a secure document in order to avoid its spurious coming up. If you do get it, please let me know by e-mail (regan@cs.buffalo.edu); you may also read this. Finally, when you dismiss the "Thanks!" page, you should probably see a message telling you you're back to accessing insecure documents.
Because the "Thanks!" page resides on the same machine as the secure-registration form, if you don't get it, it probably means that a breakdown occurred before your information was transmitted.
The server will periodically be down---if so, it will/should refuse to give you the registration page to begin with. What can also happen is that after you click "Submit", your browser chugs for a long time and (maybe) finally comes back with "Document contains no data" or a similar message. This is most likely due to failure to find a network path and means that your information was not transmitted. In this case:
Feel welcome to send me other questions or advise me of other things I should say here. --Ken Regan, who did not expect to become a CGI Webmeister.