Opera SSL Manual




Security
[ Top of the document ] [ Index ] [ Home ]

Opera provides security and privacy by using the SSL Internet protocol. This protocol allows the user (you) and the server to send and receive data and be (reasonably) sure that the data has not been tampered with (security), and without anyone that eavesdrops on the transmission understanding what has been transmitted (privacy). One or both sides of the communication can be identified. The protocol DOES NOT provide any kind of information currently believed to be admissable in a court.

Opera implements this protocol for HTTP with SSL and TLS, and any document that must be loaded with this protocol has a URL beginning with https:.

SSL prevents eavesdropping by encrypting the data that is sent between you and the server. The keys used for this process are made using information swapped between you and the server using Public Key Methods and public key certificates.

Both the SSL version 2 and SSL version 3 are implemented. This means that Opera is compatible with all HTTP with SSL servers presently available. It supports so-called RSA key exchange and the C2, C4, DES and 3DES encryption methods, of which one or more are used by all HTTP with SSL servers. (C2 and C4 are compatible with the RC2 and RC4 encryption methods).

You, as the user, can control what the secure connection can do in the Security Preferences menu.

Glossary


[ Top of the document ] [ Index ] [ Home ]

HTTP: The protocol used to transfer documents and files over the World Wide Web

HTTPS: HTTP with SSL, all communication of HTTP data are made with the SSL protocol.

SSL: Secure Sockets Layer, protocol used communicate over an encrypted connection, and to authenticate none, one or both of the participants. There are two versions SSL version 2 (SSL v2) and SSL version 3 (SSL v3). SSL v3 is more flexible and considered safer than SSL v2.

TLS Transport Layer Security. Opera 3.50 was the first commercially available browser to support TLS 1.0, which is the successor of SSL. TLS in Opera offers up to 128 bit encryption. The actual strength of the encryption is "decided" by the site itself, but many servers are beginning to use this advanced protocol. This feature is naturally supported in Opera 3.60 too, giving you the chance to select which parts of the protocol you wish to have enabled.

If a site uses SSL, the TLS protocol will work (in most cases).

bit: A Single digit of a number written in the binary number system used by computers. A binary number uses only zero(0) and one(1) as legal numbers, as opposed to the decadic system (zero to 9) used by humans.

byte: Collection of 8 bits. Can represent values from 0 to 256.

Encryption: Method used to make information unreadable (scrambled) without the proper decyption (unscrambling) methods and informations.

Decryption: Method used to make information that is unreadable (scrambled) readable again by using the proper methods and information to reverse the process. Encryption Keys: A secret number or combination of numbers that are used to encrypt or decrypt data, These are most often secret (See Public Key/Private Key for a variation). The length of these keys are given in bits, and is usually used as a measure of how difficult it is to find the key, or to break the method

Public Key: An encryption key that is not kept secret, because it is used together with a Private key. Anyone can encrypt a message withe public key and know that ony the holder of the private key can read it, and everyone can read what is encrypte with the private key and know that only the holder of the private key could have sent it.

Private Key: An encryption key that is kept secret and not shared with anyone even those one communicate with, because it is used together with a Private key. Anyone can encrypt a message with the public key and know that only the holder of the private key can read it, and everyone can read what is encrypte with the private key and know that only the holder of the private key could have sent it.

RSA: Public key encryption method, named for the inventors Rivest, Shamir and Adleman. Uses simple math, but is very difficult to break, as the use of large primes is a central foundation of this method.

Public Key Methods


[ Top of the document ] [ Index ] [ Home ]

Public Key Cryptography is a method where you use two keys, one private, known only to you, and one public, that you may send to every one you are going to communicate with, or post in a database.

Some of the methods work this way:

Anything encrypted with the private key can be decrypted with the public key, and vice versa, but nothing encrypted with the public key, can be decrypted with the public key.

This means that a message encrypted with *your* private key can be read by anyone, but they will know that it *was* *you* who encrypted it. On the other hand, anyone may encrypt a message with *your* public key, and know that *only* *you* can read, by using your private key to decrypt the message.

How secure are these methods? Generally speaking, the methods in use today has not been broken except by brute force, and the amount of brute force needed depends on how large the numbers used in the keys are (Size of keys is given in number of bits).

The method used by Opera, RSA, is based on large prime number (numbers that can only divided by 1 and itself, such as 2, 3, 5, 7, 11 and 13), and the only way known to break a private key is to factor large numbers, which is a very expensive operation in work (number of caclulations), or hardware.

The largest such key that has been broken was a 428 bit key (129 digits), in 8 months. Todays methods usually uses at least 512 bit (154 digits), but more often 1024 (308 digits), and are therefore much more difficult to break; but present methods and technology is believed to be able to break the 512 bit key within a year or so, but the work doubles for every few digits.

The present rule of thumb is, more bits, more security. This means that, use 1024 bit, or more if you can; Opera presently supports keys up to 2048 bit keys, but some servers may not be able to use keys larger than 1024 bit.

These methods are generally very time-consuming, and are therefore only used to send small amounts of data usually less bits than in the key.

Public Key Certificates


[ Top of the document ] [ Index ] [ Home ]

A Public Key Certificate is a data record holding some form of identification about you, a server or a Certificate Authority and the public key you or the one whose certificate it is, are using. You may have several certificates issued for yourself, each for a different public key (and associated private Key).

Public Key Certificates assumes that the private key of the entity that issued the certificate is not compromised (that is, unavailable to unauthorized individual) and that the same holds for the private key (yours) whose public component it certifies.

A certificate is signed by a Certificate Authority using its private key. All certificates are valid in a restricted period of time, generally a year, possibly more if the keys are considered safe.

Certificate Authority keys are generally valid for years, even decades.

Opera supports two kinds of Public Key certificates, personal certificates issued to yourself, and Certificate Authority certificates issued by the CA's to themselves or to other CA's. The third kind, server certificates, are only used to authenticate the server.

A Personal Certifiate is issued by a Certificate Authority to *you* as an individual, Opera is not able to install personal certificates already issued to another browser, as it is unable to retrieve the Private key associated with the certificate. The installed certificates are listed in the Preferences-Security-Personal dialog box.

The Certificate Authority certificates are used to verify the correctness of received server certificates, and to build the sequence of certificates a client can send the server when it request a certificate. These certificates may be signed by another CA certificate, or be selfsigned, that is, it holds the CA's public key, and is signed with the corresponding private key. These certificates are listed in the Preferences-Security-Authorites dialog box, where you may select actions to be taken when a server sends a certificate that is signed directly or indirectly by the given CA; you may select to break the connection, or ask for user confirmation before continuing.

Certificate Authorities


[ Top of the document ] [ Index ] [ Home ]

Certificate Authorities (CA's) are organizations that are used as Trusted Third Parties, that is, an independent party, which both sides of a transaction (client and server) trusts.

A Certificate Authority will generally publish a Certificate Service Policy Statement on their website. This statement will state the terms on which they do business, such as what requirements different classes of certificates require, what penalties may be brought against you if you break the rules, or what the limits the CA's service and responsibilities are. Before requesting a certificate from a CA, and (possibly) even before accepting certificates issued by the CA to servers, you should read the Policy Statement and decide if they are acceptable to you.

A number of CA certificates that are commonly in use are supplied with Opera, but it is *Your* responsibility to determine if they are acceptable to you. If they are not acceptable, you should set the appropriate options for those certificates.

A Certificate Authourity will publish one or more certificates that specifies their Public Keys, which they are using to sign certificates. There are two types of certificates: Selfsigned, and CA certificates signed by another CA.

In the latter case a certificate must be available that is either selfsigned or can be followed in an unbroken chain of certificates up to a selfsigned certificate. This method may be used internally for a CA using shorttime certificates, or to certify the CA-services of external companies, who need their certificates to be recognized widely.

Certificate Authorities generally has Web pages where you can submit your request for a certificate, along with information that shall go into the certificate, such as name, address, other information, and the generated public key which is unique for each certificate. The CA will then perform a number of controls on your information, You may have to give them extra information offline, and possibly in hardcopy, or by personal attendance at one of the Certificate Authority's offices.

When all controls are finished and passed, the certificate will be issued, and you will be informed how to get it by the CA. In some cases a certificate is issued directly in responce to your submission in which case you will go directly on to Install User Certificate in the personal certificate database.

Public Key generation


[ Top of the document ] [ Index ] [ Home ]

This is the process where a random numbers are found, and through a number of calculations are converted into a private key and a public key. This process is timeconsuming, and will for large key take many minutes (on a Pentium, longer on older PC's) for the largest keys (2048 bits). Presently, we regret that this process will lock your computer while the keys are generated, and you will not be able to use it while the generation is going on. (Note: the generation takes place on *your* computer, no other computer is involved in the generation of the key).

The number of bits in the key is selected by you in the form presented by the Certificate Authority.

After the keys are generated the keys will be inserted into into your protected database, you may, depending on preferences, be asked for your Security Password that will which will be used.

Then the public key, and other necessary data are transmitted to the Certificate Authority. (Note that neither your private key, nor your security password are transmitted.) The CA will then perform a number of controls on your information, You may have to give them extra information offline, and possibly in hardcopy, or by personal one of the Certificate Authority's offices.

When all controls are finished and passed, the certificate will be issued, and you will be informed how to get it by the CA. In some cases a certificate is issued directly in responce to your submission in which case you will go direcly on to Install your Certificate in the personal database.

The public key is then sent to the certificate authority with the certificate request for signing.

Encryption methods


[ Top of the document ] [ Index ] [ Home ]

NOTE: Much of this information is technical in nature.

The encryption methods shown in the configure SSL v2/ SSLv3 box has this format:

[n]-bit [Method] ([Public key-method]/[Hash method]) This describes how many bits (<n) the encryption keys used for transmission of data have, which Method is used for data transmission, which Public key method is used to exchange the shared secrets needed and the Hash method used to verify that the transmitted data are correct.

Opera supports these encryption methods:

Authentication Only: This method does not encrypt the transmitted data, but can authenticate the server, and if necessary, yourself, and verifies that the data have not been tampered with. This method lets anyone read your data, but not change them. It may be used for transmission of already encrypted data, saving the computational time needed for the extra, unnecessary, encryption.

C2: An encryption method compatible with RC2 (developed by RSA Data Security Inc.). It can use 40 bit or 128 bit keys (128 bit only in SSL v2).

C4: An encryption method compatible with RC4 (also developed by RSA Data Security Inc.) It can use 40 bit or 128 bit keys.

DES: An encryption method developed by IBM in 1974, and certified as a US standard at least until 1998. It can use 40 or 56 bit keys.

3-DES: An adaption of DES using 3 encryption/decryption steps with 3 different keys, giving a total of 168 bit in the key.

The encryption method list is listed in ascending order depending on the number of bits in the method's key, and it's assumed security.

Presently, the only Public key method supported is RSA. It is used to verify the Public key cerificates sent by the server and the client (you), and to encrypt the shared secrets used by the server and the client. The methods in SSL version 3 that uses 40 bit keys has a limit on keysize set to 512 bit (for encryption, not signing).

The Hash methods are used to check the integrity of the data, by using the method to calculate a value from the transmitted data, and which is unique for those data, and which cannot be used to find out anything about the data. The two methods used by Opera are called MD5 (developed by RSA Data Security Inc.) and SHA (developed by the US government).

How secure are these methods?

The Authentication Only method provides no privacy, but insures that the data has not been tampered with.

Presently, the strength of the other methods is derived from the number of bits in their keys, as for each extra bit the number of possible combinations doubles, that is, 40 bits give a 12 digit number of combinations, 56 bit is 16 digits, 128 bit is 38 digits, and so on.

For none of C2, C4, DES and 3-DES has there been found an easier way to find a key than by trying every one of the possible keys. That means that for each message you want to break, you will have to do the job all over again. For somebody with a lot of computers this means a few hours for a 40 bit key, a couple of months for a 56 bit key. More than 10,000 PC's using idle time, a dedicated set of supercomputers might break it in less. (A specially constructed DES breaker at the cost of $250,000 USD was able to break a 56 bit DES in 3 days in the spring/summer of 1998. This used about 1500 DES units controlled from one PC.) At present technology the other methods a talking millions or billions of years (unless somebody finds the golden formula). For the next few years the 128 bit methods can be considered quite safe, DES (not 3-DES) may be vulnerable, but somebody must want your data badly if they're going to try to break it (presently).

The hash methods are used to create a short identification for a given message. This identification can, by definition be the same for two or more messages, but it is incredibly difficult to find such messages, much less one you can use, or which is the original message, or to find the secrets needed to forge such a signature.

How do I know how secure the connection is?

In the low left corner of the document window the security status of the document is shown. It is the lowest security status among the subdocuments loaded.

The security ratings are:

- "No security" - for documents without any encryption or authentication.
- "Low Security" - for vulnerable keys methods with 32 to 64 bit keys
- "Medium Security" - for keys with a little more security, 64 to 96 bits.
- "High Security" - for secure methods 96 bit keys and above, with the exception of SSL version 2 methods.
SSL v2 will be phased out due to certain weaknesses within the next few years.

Which methods do I select?

Generally speaking, the 128 bit C2 and C4, and 168 bit 3-DES are recommended. Depending on the server you are connecting to, you may need some of the others. This is especially the case if you are going to communicate with servers outside of the US, that are produced by Netscape, Microsoft, other USA based vendors, or based on US encryption software, and which are located outside the USA. Then you will have to enable the 40 bit methods as well. With servers such as Stronghold and Apache with SSL, the 40 bit methods are not needed at all.

Install Personal Certificate


[ Top of the document ] [ Index ] [ Home ]

The displayed certificate or certificate chain will be installed if you press the OK button, if you press Cancel they will be discared.

The first certicate in the chain must have a public key that matches the public key of a private key already in the database. If there is none, the installation will fail.

The remaining certificates, if any, must be the certificate of the signer of the personal certificate, That certificate must either be selfsigned (and the last certificate), or be signed by the next certificate in the list. These certificates are installed in the Certificate Authorities Database if they are not already installed, and will cause a warning to be issued if a server sends a certificate signed by the new authorities.

Install a Certificate Authoritiy Certificate


[ Top of the document ] [ Index ] [ Home ]

The displayed certificate or certificate chain will be installed if you press the OK button, if you press Cancel they will be discared.

That first certificate must either be selfsigned (and the last certificate), or be signed by the next certificate in the list.

The first certificate is installed in the Authorities Database if not already installed, with the selected actions (Deny access, warn if used by server) set. The remaining certificates are installed in the Authorities Database if they are not already installed, and will cause a warning to be issued if a server sends a certificate signed by the new authorities.

Install a PEM encoded Certificate


[ Top of the document ] [ Index ] [ Home ]

This box is shown if you load a cerificate holding a PEM encoded certificate. The actual installation procedure depends on this certificate being a personal certificate or a Certificate Authority certificate, which is determined after you press OK.

Because of the dual nature of this box you may set the authority flags, but they will not be used for a Personal Certificate.

If the first certicate in the chain has a public key that matches the public key of a private key already in the database, that certificate will be considered a personal certificate and installed in the Personal Database, otherwise it will be treated as a Certificate Authority certificate.

The remaining certificates, if any, must be the certificate of the signer of the personal certificate. That certificate must either be selfsigned (and the last certificate), or be signed by the next certificate in the list.

These certificates are installed in the Authorities Database if they are not already installed, and will cause a warning to be issued if a server sends a certificate signed by the new authorities.

Warnings


[ Top of the document ] [ Index ] [ Home ]

These are messages about conditions that are not directly fatal for the connection, but which you may cause to decide that the connection should be closed. Generally you can continue with OK, and close the connection with Cancel. The connection may however be taken down even if you press OK, as the server may not desire a continued connection.

Warnings may be sent by Opera, or by the server; the title of the window says which end sent the warning. Generally, a warning from the server indicates a problem caused by Opera, and vice versa.

The following warnings can be issued (some may also be given as fatal errors):

Unsupported Certificate: The certificate cannot be handled by the sender.

Certificate Revoked: The certificate has not expired, but the certificate has been invalidated for other reasons.

Certificate Expired: The certificate is no longer valid (or not yet valid)

Certificate Unknown: A certificate could not be verified for some unspecified reason.

Fatal Errors


[ Top of the document ] [ Index ] [ Home ]

These are messages about conditions that are directly fatal for the connection, and the connection will be shut down immediately, and the message is used to inform you about the cause of the failure.

Warnings may be sent by Opera, or by the server; the title of the window says which end sent the warning. Generally, a warning from the server indicates a problem caused by Opera, and vice versa.

The following fatal errors can be issued:

Handshake Failure: Some problem caused the (re)negotiation of the connection to fail. This *may* happen because you and the server could not find, common (enabled) encryption method or, less likely, by outside tampering with the data. Other reasons also exists.

Transmission Failure: Some problem occured during ordinary communication. This *may* happen because of illegal data or, less likely, by outside tampering with the data. Other reasons also exists.

Bad Certificate: The certificate could not be verified properly, this may be caused by a faulty signature on one of the certificates.

Access denied: The certificate was valid but you have specified that certifcates signed by one of the signers in the chain is not to be trusted.

Invalid Certificate Chain: The certificates in the chain of a received Server Certificate, or a certificate that is to be installed was not ordered properly.

Internal Error: Some local problem caused the connection to fail. One possible reason is out of memory conditions.

No Cipher Selected: You have not selected any encryption methods.

Security Disabled: You have disabled security.

No Cipher: You had not enabled any of the SSL version 2 encryption methods acceptable to the server. This message will only appear for SSL version 2, SSL version 3 gives a handshake failure message.

You may also receive messages about not having enabled SSL version 2 when connection to a server using only version 2, and you have not enabled it.

Certificate verification and warnings


[ Top of the document ] [ Index ] [ Home ]

When Opera receives a chain of Public Key Certificate from the server it will verify the authenticity of the certificate(s) by checking that the chain verify correctly, and that the certicate can be traced to one of the Certificate Authority Certificates in the database.

If the certificates cannot be traced to an installed certificate, Opera will ask you if you accept the certificate and the server as legitimate. If you accept the server you will not be asked again while Opera is running. If you shut down Opera the list of accepted servers is not stored to the disk.

If such certificate chain actually included a selfsiged root certificate, you have the option of installing the root certificate into the database and to set the flags for its use. By installing the certificate, and not unchecking the allow connection flag, you will, implicitly, accept the server.

If the chain is found to be correct, Opera proceeds to check the database entires of those Certificate Authorities that have signed certificates in the chain (at least the top certificate will be present in the database).

If for one (or more) of these Authorities you have unchecked the allow connection flag, you will be shown a Access denied fatal error message, and the connection will be shut down.

If you have Allowed access, but have checked the Warning option for at least one of the Certificates Authorities you will be shown the certificate and asked to accept it. Such warnings will be shown each time such a certificate is received, even if it has been accepted before.

If none of the conditions above occur, Opera will continue the SSL connections without needing input from the user.

NOTE: It is YOUR responsibility as the user to decide if you are willing to trust any specific WWW-site, SSL-enabled or not. This is especially true when doing business transactions. The Certificate Authorites generally require a lot of verifiable documentation about the operators of the sites that are issued a certificate, but it is always possible to fool the CA, or the operator may be less than a serious businessman. Opera provides some means to weed out or flag the completly unserious or dubious Certificate Authorities, But YOU will still need to evaluate each of the servers you plan to do business with.

Passwords


[ Top of the document ] [ Index ] [ Home ]

The Private Keys that you have generated, and whose Public Key parts are used in your certificates are stored in an encrypted, password protected database.

There are no limitations on the length of the password, and what characters you may use. A password may have several words, and or characters that are not ordinarily used in words like ".:;^*|ยง", and others. It is therefore not quite correct to call the security password a password. If you think your system is *very* safe, and no one will *ever* get to your data, you choose not to use a password. However you should know that most Certificate Authorities require you to keep the private part of the Public Key they certify safe.

The first time you generate a key you will be asked to enter a security password, and then to reenter it. You may also change the password at almost any time (in Preferences-Security) but do not change the password while you have active SSL-connections. Depending on what you have set you password preferences (in Prefernces-Security) to, you will only need to enter the password once per run of Opera, or each time the database is accessed (i.e., when you insert new keys, or uses one, you are not asked when inserting a certificate.)

How do I select a good password?

First, **NEVER** select the birthdays or the name(s) of your wife, husband, girl-/boyfriend, children, parents, favorite artist or TV-character or movie, your dog or cat, words that are in the dictionaries (of any language) or citations from literature; If somebody want to break your password (or any password) they will not just have these items and more on hand, they will use them automatically.

A password should be obscure, as long as necessary, and it should have a mixture of alphabethic charachter, both small and large case, numbers and other charachters; the more, the merrier. With todays efficiency at breaking keys by brute force a moderately secure password should be 10 random charachters or more, a really secure more than 20 random characters (change characters to words if you are using readable words). And of course you should be able to remember the password, and not write it down on paper or anything else.

How secure is the private key database?

Aside from the selection of passwords (over which Opera has no control), each private key is encrypted with a 3-DES encryption key different from every other key used to encrypt other private key's in the database. This means that short of finding the password, it is today unfeasible (note: *one* 56 bit single-DES key was bruteforced in two months in spring 1997, but 3-DES has 168 bit key and those are theoretically 10^33 times more difficult to break) to break one encryption key by brute force, much less the entire database. In other words, your keys are stored as securly as your choice of password allows them to be.

SSL Problem handling


[ Top of the document ] [ Index ] [ Home ]

If you get a "failed to connect" message, you should try to: