The "Calomel SSL Validation" add-on grades the SSL cipher strength of the current connection. Access to a detailed summery of the SSL negotiation is supplied by a toolbar button. The button will change color depending on the grade from red (low score), to yellow, to blue and finally to green (high score). Standard HTTP unencrypted connections will turn the toolbar icon gray as will any blank tabs.
In the options section you can enable the use of only the strongest 256 bit ciphers in high security mode in addition to disabling the Online Certificate Status Protocol (OCSP). Other tabs include speed optimizations, the ability to turn off page and DNS prefetching, tab previews and an option to disable annoyances like blinking text and gif animations.
To install in Firefox, go to the official Mozilla Firefox Add-on page for "Calomel SSL Validation". There you can find screen shots too!
IMPORTANT: Development of the Calomel SSL Validation addon has been put on hold. Mozilla is disabling XUL and XPCOM in Firefox which means the addon is no longer able to query the current browser tab for the TLS certificate and cipher information.
Mozilla is introducing a new framework called WebExtensions which all new addons must use, but WebExtensions are not allowing addons to query the TLS certificate and cipher at this time.
You can use Firefox's Network Security tab to retrieve the same TLS information the addon was collecting.
To use Firefox's Network Security tab:
For more information about certificate hashing we recommend searching Google for, Transitioning your certificates to the SHA-2 hashing algorithm. We also have Nginx tutorials including nginx.conf to help site owner setup a secure server.
For this example we are going take a look at the details in the current toolbar button drop down box for this site with the "all ciphers allowed" security group chosen. Push the "green " URL button of our add on to see the drop down panel. If you do not currently see the toolbar button right click on the top tool bar, go to "customize" and scroll down to the bottom of the icon list. There you will see the "Calomel SSL Validation" button in gray. Just drag the button on to the toolbar. We like the placement to the left of the URL bar, but the position is completely up to you. You may need to refresh the page for the icon to turn the correct color after the install.
This is the overall security profile of the SSL connection. The connection could be "very strong", "strong", "moderate", "weak" and "very weak" and will only be shown when the SSL connection is established and is encrypted in some way. In the parentheses is the color description of the URL icon button and the score of the page up to 100%. The color description was added for users who are color blind and may not be able to distinguish color hues. The score gives a more detailed idea of how securely Firefox connected to this site.
This describes the response from the certificate authority server. The certificate must be able to be verified through a certificate authority (CA) or be verified by the user for a self signed certificate. If the certificate is verified the status message "Verified" is received and the pass score is given. If the user has authorized a self signed certificate as "good" then a pass value will also be awarded.
If there is a problem with the certificate or it can not be verified then the entire SSL connection is suspect. A suspect certificate is awarded a score of negative one hundred (-100) to guarantee a red URL icon. An example of the failed verification is a self-signed cert which has not been approved by the user or an expired or revoked certificate. The foundation of a SSL certificate is having a third party positively verify the cert or having the user authorize the cert independently of external sources. If the certificate authority reports a problem with the cert, the cert is invalid or the user can not independently verify the cert then we can not trust it.
Class is the type of background check the certificate authority does to the buyer of the server certificate. Calomel.org uses a standard SSL certificate from Comodo SSL and they award us a "Domain Validation" or "DV" certificate. This means that Comodo SSL only verified that the owner of the domain, that is us, bought the cert for calomel.org. A DV class certificate is a very simple and fully automated verification process done by the certificate authority (CA) and is good enough for 99% of web sites.
The other type of validation is "Extended Validation". An "EV" certificate is for companies as the verification process is significantly more stringent and more expensive. While a DV cert might cost as little as two(2) US dollars per year and EV cert cost hundreds of dollars per year. In order for EV certificates to validate you MUST make sure OCSP checks are enabled.
We do not score on this value as anyone can get an EV certificate. Most small sites and companies will not bother with EV certs, but organizations like banks and financial institutions might to make their users "feel" more secure. Understand that there is absolutely no difference in the encryption profile between a DV or EV certificate.
This is the address of the fully qualified domain name (FQDN) of the server shown in the URL bar. This string should match the name of the domain you wanted to go to.
The "Common Name" is the primary full domain name string the SSL certificate is registered for. The "URL host" above and the "Common Name" should match for the SSL certificate to be valid. Firefox does a regular expression test and if both the URL and any host in the certificate Common Name match then the tag, "(matched)" is printed. If the "Common Name" and "URL Host" the connection will get a negative one hundred (-100) score and a red icon. Scroll to the next section for the description on how we score the connection.
The certificate must specify the domain name they want this cert to support. If the website owning the domain is "www.google.com" then the certificate must be registered with the "Common Name (CN)" of "www.google.com" or at least the glob "*.google.com". If the domain is mismatched then validation instantly fails.
NOTE: If you manually add a "Security Exception" for a URL which points to an https domain name then that URL will match the https domain name. For example, if you go to one of the ip addresses of encrypted.google.com, namely https://74.125.225.32/ , you will see the ip does NOT match the common name in the certificate of encrypted.google.com. This error is expected and Firefox as well as our addon show a warning. If you then add a "Security Exception" to the https://74.125.225.32/ URL, Firefox internally symlinks https://74.125.225.32/ to encrypted.google.com because _YOU_ manually allowed the exception. Now, both https://74.125.225.32/ and encrypted.google.com are now equal according to Firefox and are now "matched" Common Names. This is not a bug, but a feature for advanced users. Please be careful when adding SSL certificate exceptions as they can cause confusion and are not that easy to remove.
Perfect Forward Secrecy (PFS) allows the cipher to use a new random master key for every connection between the server and every client. PFS is more secure. Non-PFS ciphers use the server's private key for encryption. If the server's private key is ever compromised then all past communication from the server to all clients can be decrypted. With Perfect Forward Secrecy every connection uses a unique negotiated key exchange so even if the server's private key is compromised, no past communication can be decrypted. Our goal is for every server to exclusively use PFS ciphers all the time, for every client. Calomel.org is a PFS only site.
The cipher suite is the full cipher string collected directly from Firefox. We included it so you could independently verify the raw cipher string in case our add on did not classify the cipher accurately. This line is then broken out into component pieces and graded individually in the following lines.
The Transport Layer Security (TLS) protocol guarantees privacy and data integrity between client and server applications. TLS version 1.2 is the newest, and most secure version and receives the full score. Valid strings are TLS v1.2, TLS v1.1, TLS v1.0 and SSL v3. In the newest versions of Firefox SSLv3 is no longer allowed due to the POODLE attack vector, but we will keep the SSLv3 check in place in case the Firefox defaults are overridden.
A cipher key exchange is the method the server and client use the exchange symmetric keys between each other. The use of the Elliptic curve Diffie Hellman Ephemeral (ECDHE) key exchange means this connection has Perfect Forward Secrecy (PFS) due to the "E" or Ephemeral portion and speed due to the nature of the Elliptic curve (EC). DHE is also secure, but DHE is deducted points because it is at least twelve(12) times slower then ECDHE (64 bit) which is bad for mobile client devices. Valid strings are ECDHE, DHE, ECDH, DH or RSA. In order to get full points the key exchange should be ECDHE.
The signature is the method the certificate authority chooses to sign our public key certificate with. Most certificate authorities (CA) today use the standard RSA method. Comodo SSL and Google are their own CA, so they use the significantly faster Elliptic Curve Digital Signature Algorithm (ECDSA) method. The signature is not rated as both RSA and ECDSA provide similarly secure signatures. The certificate signature type and bit length is rated below in the "Issued to" and "Issued by" section.
The bulk cipher and bit length is the symmetric cipher used to transfer data once the connection is established and keys are exchanged. AES 128 bit and 256 bit are quite strong and will get the highest score. Other ciphers you may see are RC4 128 bit, Triple DES (3DES), AES 128, IDEA, DES, or Camellia. In order to get full points the cipher must be AES at 128 bits or 256 bits.
The MAC or message authentication code (primitive) is used to authenticate a message to provide integrity and authenticity assurances on the message. Integrity assurances detect accidental and intentional message changes, while authenticity assurances affirm the message's origin. SHA-1 is the most common MAC, but SHA-256 is now available to site owners as well as the adoption of TLSv1.2. The only way to get the full points is the use of AES Galois Counter Mode (GCM) ciphers and the AEAD message authentication code. All the latest major browsers support at least two(2) GCM, 128 bit ciphers.
This field is blank for us. Normally, you will see the name of the company, individual or organization which purchased the SSL certificate. This value is not used in the scoring of the site as it can contain any string or even be left blank. This field could contain the URL host, company name, individuals name or any variation.
This is supposed to say the location we added to our certificate. The problem is calomel.org currently uses a free cert from Comodo SSL and they do not honor the location information from our CSR. For other sites you will see the location information that site registered their certificate for. For example, Google's location information is "Mountain View California US".
This is the algorithm the certificate signing request (CSR) was signed with before it was sent to the certificate authority. We use Elliptic Curve Digital Signature Algorithm (ECDSA) with a 256 bit prime curve and SHA-256 hash. If the site uses RSA instead, the hash and bit size will be shown; similar to "SHA-256 With RSA @ 2048 bit". This format translates to a SHA-256 hash with a key size of 2,048 bits. A SHA-1 hash of 2048 bits or more is weak and only SHA-256 at 2048 bits are considered strong. The string "Curve" instead of a numerical bit value stands for Elliptic Curve Digital Signature Algorithm, or ECDSA. In order to receive the full score a site must use Elliptic Curve DSA or SHA-256 at 2048 bits or higher.
The name of the certificate authority who provides the certificate to the buyer; in this case the seller is Comodo SSL, This is also the entity who houses the SSL validation servers used by Firefox to verify that calomel.org is a valid hostname to use this certificate for. This value is not use in the scoring of the site.
The location of the certificate authority's corporate offices. In this case the location of Comodo SSL identity is registered in Great Britain.
This is the algorithm the certificate from the certificate authority was signed with. Comodo SSL is one of the first CA's to sign their certificates with ECDSA all the way up to the root certificate. Comodo SSL's intermediary certificate is signed using a 256 bit prime curve and a SHA-384 hash. If the site uses RSA instead, a string similar to "SHA-256 With RSA @ 2048 bit" is shown. The size of the key is 2,048 bits. A SHA-1 hash of 2048 bits or more is considered weak. The full score will only be awarded to sites hashed with ECDSA or RSA of SHA-256 at 2048 bits or higher.
This is when the SSL certificate account was first activated and allowed to be verified by browsers like Firefox. This value is not used in the scoring of the site, but if the "Valid from" date is in the future the certificate is invalid and a red button is awarded. Certs can not be used before or after their "valid" dates. Note that re-issued certificates can have the same "from" and "until" dates. It is up to the certificate authority (CA) on what dates to implement and the "Valid from" date may not be updated even when the certificate is reissued. The only way to guarantee the dates will be updated is to buy a brand new certificate.
This is the expiration date of the certificate by the certificate authority. This certificate can not be verified past this date. The site owner will have to buy a new cert after this date has passed if they wish to continue using SSL. This value is not used in the scoring of the site, but if the "Valid until" date is in the past the certificate is invalid and a red button is awarded with a score of zero(0).
The add-on will score the SSL connection and change the color of the icon in the URL bar. In the drop down box the details show the percentage score on the first line. The colors of the URL button are red (none or weakest security), to yellow, to blue and finally green (strongest security).
The score of a site is currently made by:
Perfect Forward Secrecy (PFS) is a property of the key-agreement protocol that ensures a session key derived from a set of long-term public and private keys will not be compromised if one of the (long-term) private keys is compromised in the future. PFS is a very good way to make sure past communication is not decrypted with the lose or compromise of the server key.
The Transport Layer Security (TLS) protocol guarantees privacy and data integrity between client and server applications. TLS version 1.2 is the newest, and most secure version and receives the full score. Valid strings are TLS v1.2, TLS v1.1, TLS v1.0 and SSL v3. In the newest versions of Firefox SSLv3 is no longer allowed due to the POODLE attack vector, but we will keep the SSLv3 check in place in case the Firefox defaults are overridden.
Key exchange (also known as "key establishment") is any method in cryptography by which cryptographic keys are exchanged between server and client, allowing use of a cryptographic algorithm. A strong key exchange method is critical to the setup of the encrypted communication.
A symmetric bulk cipher is the algorithm used to encrypt the data sent over SSL. You want to negotiate with the remote server to use the strongest ciphers available to both systems. In our case we are looking for the Advanced Encryption Standard (AES) at 256 bits or even Camellia at 256 bits for the highest score. If the SSL connection is negotiated at AES 128 bit, Camellia at 128 bit or even Triple DES at 168 bits then a lower score is awarded. If the weak RC4 cipher is used the connection is awarded the lowest value. A very weak cipher would be an export controlled 40bit MD5 cipher for example.
The key length is in bits. The larger the key the higher the score. Keep in mind that the type of symmetric bulk cipher used is significantly more important than the size of the key. A 256 bit key will get the highest grade.
The message authentication code (MAC) is a short piece of information used to authenticate a message and to provide integrity and authenticity assurances on the message. Integrity assurances detect accidental and especially intentional message changes, while authenticity assurances affirm the message's origin. SHA-1 is the most common MAC, but SHA-256 and SHA-384 are becoming more common with the introduction of TLSv1.2. Only AEAD, AES Galois Counter Mode (GCM) ciphers get full credit.
If the certificate uses SHA (SHA-256 through SHA-512) it is considered "STRONG". If MD5 or SHA-1 is used the cert is rated as "WEAK". A bit type of "Curve bit" stands for Elliptic Curve Cryptography (ECC) Certificates which are significantly stronger then RSA certs and thus awarded the "STRONG" value. A RSA length in bits of 2048 and above is considered "MODERATE" and anything less is weak. In order for the certificate to be rated as "STRONG" both the hash and the key length have to be rated strong. If either one fails the entire hash rating is "WEAK".
At the RSA Conference 2005, the National Security Agency (NSA) announced Suite B which exclusively uses ECC for digital signature generation and key exchange. The suite is intended to protect both classified and unclassified national security systems and information. The Elliptic Curve Digital Signature Algorithm (ECDSA) is a variant of the Digital Signature Algorithm (DSA) which uses elliptic curve cryptography. For more information on ECC take a look at Wikipedia's Elliptic curve cryptography page.
There is nothing secret or mystical about a Firefox Add-on, this one is no different. We will try to explain in detail all of the methods we use and tell you exactly which "about:config" values we trigger. This way you can make an informed decision whether to use an option or not.
Helpful Hint: To get to the preferences menu, middle mouse click on the addon's colored button. The add-on preferences are also available at the bottom of the "Tools" menu under "Calomel SSL Validation". The longest route to the add on's options is to navigate through Tools, Add-ons, Extensions and the Preferences.
This option enables only the highest strength 256bit, ChaCha20 and GCM block ciphers which are perfect forward secrecy (PFS) enabled. This option also disabled SSLv2 and SSLv3 and only allows TLSv1, TLSv1.1 and TLSv1.2. The following list ordering is not important as the server chooses the preferred cipher order.
These are the current ciphers and configuration this option will trigger:
This option enables 256bit and 128 bit SSL ciphers which are perfect forward secrecy (PFS) only. This option also disabled SSLv2 and SSLv3 and only allows TLSv1, TLSv1.1 and TLSv1.2. The following list ordering is not important as the server chooses the preferred cipher order.
These are the current ciphers and configuration this option will trigger:
This option enables 256bit and 128 bit SSL ciphers including perfect forward secrecy (PFS) as well as RC4 128 bit and Camellia. This option also disabled SSLv2 and SSLv3 and only allows TLSv1, TLSv1.1 and TLSv1.2. The following list ordering is not important as the server chooses the preferred cipher order.
These are the current ciphers and configuration this option will trigger:
This option simply enables all the default ciphers allowed by Firefox. If you wanted to deny our addon from modifying any of the ciphers or you are using another addon to modify ciphers then choose this option. You can also choose this option for the greatest website compatibility as even the weakest ciphers will be allowed.
Toggle Ciphers: To toggle ciphers just open up the preferences menu by middle mouse clicking on the shield icon. Choose the option you want a click the "Apply Changes Now" button. Rise and repeat.
Verify Client Ciphers: You can verify a browser's supported cipher suite using the "How's My SSL dot com" client test page. If you go to any site and Firefox shows the error, "Error code: ssl_error_no_cypher_overlap" then the site you went to does not support any of the high level 256 bit ciphers listed above.
Addon Update Notice: When you enable high strength 256bit ciphers then Firefox's automatic add-on updates will break. The reason is the Mozilla add on site only accepts the very weak RC4 cipher.
In order to periodically update all your add ons it is recommended to open up the addon preference's window. Choose the "all ciphers allowed" option and click the "Apply Changes Now" button. Then go into the "Add-ons" page under "Tools" and "Check for Updates" manually using the little lightswitch or gear icon. You can then restart Firefox after updating any addon. Make sure to go back to the preferences window and re-enable your preferred restrictive cipher suite. We understand this is not an ideal solution, but Mozilla is not using secure ciphers and high strength ciphers are exactly what the more restrictive cipher suites turn on.
In order to communicate securely, a TLS client and TLS server must agree on the cryptographic algorithms and keys that they will both use on the secured connection. They must agree on these items:
There are numerous available choices for each of those categories, and the number of possible combinations of all those choices is large. TLS does not allow all possible combinations of choices from those categories to be used. Instead TLS allows only certain well-defined combinations of those choices, known as Cipher Suites, defined in the IETF RFC standards. We have selected the highest strength ciphers for this option.
The client and server need to support the same cipher to be able to properly negotiate a connection. The above ciphers are those that are available for our client. The server has another list of ciphers it was built with.
A TLS client and server negotiate a stateful connection by using a handshaking procedure. The handshake begins when a client connects to a TLS-enabled server requesting a secure connection, presenting a list of supported CipherSuites (ciphers and hash functions like the ones listed above). From this list, THE SERVER CHOOSES the cipher and hash function that it also supports and notifies the client of what the connection will use.
Note that some servers have been configured to use less secure ciphers over the more secure variant to save on CPU processing time. Google (https) is like this. They prefer using the weak RC4-128 cipher. Using the AES-256 ciphers will force Google to use greater strength encryption.
This is because the admin or owner of those sites prefer to use _only_ weak ciphers and do not offer the stronger ones. They probably only accept the RC4 because of the BEAST attack or even export controlled ciphers. We chose AES over RC4 as patches for the BEAST attack (1/n-1 and not 0/n) have been available for almost a year now. Some sites do not allow our client to negotiate with the strong encryption we request.
To connect to sites which only support weak ciphers simply choose a weaker cipher level in the addons options and reload the page. When you are done just select the strong cipher tier and hist the "Apply Changes Now" button.
The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of SSL certificates. OCSP responses are encoded in ASN.1 and are usually communicated over HTTP. In order for Firefox to display the "green bar" to distinguish an Extended Validation (EV) certificate, OCSP requests must be made for every single certificate in the chain whereas in many browsers, if an OCSP request is made at all, intermediate certificates are not checked. The increased time taken for the TLS handshake when using an EV certificate can be attributed to Firefox's slow serial OCSP checking behavior. In our humble opinion, OCSP certificate revokation does not work, the OCSP infrastructure is too fragile and browsers are not stopping page loads when OCSP calls fail. We disable Online Certificate Status Protocol (OCSP) checks.
The OCSP stapling Wikipedia page states, "OCSP checking also creates a privacy concern for some users, since it requires the client to contact a third party (albeit a party trusted by the client software) to confirm certificate validity. A way to verify validity without disclosing browsing behavior would be desirable for this group of users." Speed and optimization among browsers has made it necessary to largely ignore OCSP response failures, creating a security vulnerability. OCSP stapling is a better solution to real time OCSP checks. Calomel.org, for example, supports OCSP Stapling. You can use openssl to take a look at our X.509 cert with "openssl s_client -connect calomel.org:443 -tls1 -tlsextdebug -status" and look for the area starting with "OCSP Response Data:". When Multiple OCSP Stapling is standardized then all the intermediate certificates can also be stapled by the server and sent to the user. CA Security mentions, "A switch from client-managed revocation checking to server proxied revocation information will increase online security by permitting clients to treat missing OCSP information as a serious concern. Also, multi-stapling will immediately increase performance of websites by eliminating the time clients currently need to spend establishing the connections used to download OCSP and CRL information, which can be a significant fraction of the time spent on the handshake with the server."
The problem is OCSP and CRL requests increase page load times and are susceptible to blocking by man-in-the-middle attackers or captive portals, sites commonly use Wi-Fi access points to prevent HTTP connections before users authenticate. Google Chrome and all mobile devices disable OCSP for this exact reason. Not using OCSP can make SSL pages load faster as the median time for a successful OCSP check is around 200ms and the mean is nearly a second. The Netcraft Certificate revocation and the performance of OCSP paper looks at the latency delay of many OCSP servers.
The following option is triggered:
When you disable this option all of the ciphers return to their default values.
Limit ssl connections to only those which support Transport Layer Security (TLS) version 1.2. This option is used to deny connections like SSLv2, SSLv3, TLS1.1 and TLS1.0 and only allow TLSv1.2. If you go to a site a receive the error, "Error code: ssl_error_no_cypher_overlap" then the site does not support the TLS version or the site does not support any of the cipher you restricted Firefox to. Many sites are old or misconfigured and we find around 60% of the https sites will fail when restricted to only TLSv1.2. This option is good for testing though. Calomel.org prefers TLSv1.2 and stronger GCM ciphers.
The following option is triggered:
When you disable this option all of the ciphers return to their default values.
When you type in a short name like "calomel" in the URL bar Firefox does not know where to go. So it guesses. It infers you wanted to go to www.calomel.com; but this is not where our site is located. The site you wanted to actually go to was calomel.org. Firefox should not guess where the user wants to go and this could open up privacy and security problems link typo squatting and fishing scams.
Another problem is if the user types the URL wrong. What if you typed "centralbank" instead of your actual bank, "central-bank". You may be connected to a person typo squatting your financial institution. Typosquatting, also called URL hijacking, is a form of cybersquatting which relies on mistakes such as typographical errors made by Internet users when inputting a website address into a web browser. Should a user accidentally enter an incorrect website address, they may be led to an alternative website owned by a cybersquatter.
We suggest disabling this option. The browser should not infer where the user wants to go. If we type the wrong URL into the bar then we want to see an error.
The following options are triggered:
When you disable this option all of the option return to their default values.
These are a collection of "safe" speed optimizations we found to increase the responsiveness of Firefox while reducing the CPU load and bandwidth usage. Keep in mind that these options a similar to what you find in FasterFox, but we only enable configurations considered safe and non-abusive to remote servers. If you enable these options the use of FasterFox would be unnecessary.
When you use a proxy server you are sending you http and http requests through the remote machine. It make sense to also send you dns requests through the proxy. If you do not, then even if your web traffic is proxied your DNS requests are not. This means the DNS admin at your location can look at what DNS requests you have made and infer where you are going.
For privacy and security this option send your DNS requests over the proxied connection
This option is especially useful if you setup a ssh tunneling proxy. You can find our detailed tutorial at Calomel.org's Proxy Firefox through a SSH tunnel.
The following option is triggered:
When you disable this option all of the proxy options return to their default values.
Firefox renders web pages incrementally. It displays the parts of the page that has been received before the entire page has been downloaded. What you see is the same web page being re-rendered every time another object, like a picture, has been received. This a CPU intensive task since the start of a web page normally doesn't have much useful information to display. A better solution is if Firefox should wait a short interval before first rendering a page.
We set the delay to 2000 milliseconds. This is the maximum amount of time Firefox will wait to start rendering the page. If all of the parts of the page are received before this time the page is displayed immediately. We will also set the notification interval of the browser rendering engine to 1 million microseconds (1 second) before the total of 5 refreshes is reached. The overall effect is pages using less CPU time and rendering the complete page more quickly.
The following option is triggered:
Lower values will make a page initially display more quickly, but will make the page take longer to finish rendering.
When you disable this option all of the options return to their default values.
Link prefetching is when a web page hints to the browser that certain pages are likely to be visited next. Firefox downloads them immediately so they can be displayed from cache _if_ the user requests them.
Though this sound like a great idea it adds a lot of CPU overhead and uses excessive bandwidth. You may prefer to only download pages for which you ask for, and only when you ask for them.
The following option is triggered:
When you disable this option all of the options return to their default values.
If you have a decent amount of ram (i.e. 2gig or more) in your system then you may want to think about caching _only_ to RAM. Normally, Firefox will cache most of the objects from a web page onto the hard drive. You can speed up browsing very slightly by caching those objects into ram only. Caching to RAM is also attractive if you clear cache frequently, clear all caches when Firefox closes or want to make sure nothing is put on the hard drive for privacy reasons.
By default, Firefox will look at how much RAM you have in your machine and will decide how much RAM for cache purposes it will use. Firefox automatically decides the maximum memory to use to cache decoded images and chrome objects based on this table.
browser.cache.memory.capacity="-1" autoset
Physical RAM Memory Cache
32 MB 2 MB
64 MB 4 MB
128 MB 6 MB
256 MB 10 MB
512 MB 14 MB
1 GB 18 MB
2 GB 24 MB
4 GB 30 MB
8 GB and up 32 MB
To make ram caching work we simply disable disk caching. This forces Firefox to place all web page objects that would normally be cached on disk, into ram. We also increase the amount of cache in RAM to 128 megabytes from the amount specified in the table above. If the amount of objects that need to be cached exceeds the amount of RAM cache you have, Firefox will simply gets rid of the oldest unused objects. Lastly, we disable offline disk cache.
NOTE: we do not recommend using this option is you have less than 1 gigabyte of ram in your system. The reason is we allow Firefox to use up to 128 meg to cache objects and if the system does not have a lot of RAM you may start to use swap on the hard drive. To check what Firefox is caching you can use the Calomel sub menu under the "Tools" menu.
The following options are triggered:
When you disable this option all of the caching options return to their default values.
This option will clear the title and icon normally seen in the current tab. If you are concerned with people looking over your shoulder at your browser to see what sites you have open, this is a good idea. If you take advantage of this option, the use of a add-on like "Page Title Eraser" would be unnecessary.
There is also a toggle option under the "Tools" menu. The toggle only temporary turns on or off tab titles and icons. When Firefox is restarted the option you preferred in the add-ons preferences will be restored.
Firefox incorporates the "Google Safe Browsing" extension in its own "Phishing Protection" feature to detect and warn users of phishy web sites. This sounds great, but most of the time you will never see the result of this feature. In fact, unless you are normally going to the darker edges of the Internet you may have never seen this Firefox error pop up.
There are two reasons we see to disable this function. Privacy and speed. Every time you go to a site, change a URL or do anything that information is sent to Google to be checked. This is violation of privacy as Google will track everything your ip does and everywhere you go. Disabling this option is also a way to gain some much needed response times. Every time you go to a new URL Firefox send a request to Google and this takes time. Once the request has been received from Google it is cache locally, but looking up the request in the look up file also takes time.
The following option is triggered:
If you are worried about shady sites it is much more secure to turn off all Java scripting than use the "safe browsing" option. Take a look at the NoScript add-on. It will keep you much safer than this option ever could; and it won't track your every click.
When you disable this option all of the options return to their default values.
When you visit a location-aware website, Firefox will ask you if you want to share your location. If you allow geo reporting, Firefox gathers information about nearby wireless access points and your computers IP address. Then Firefox sends this information to the default geolocation service provider, Google Location Services, to get an estimate of your location. That location estimate is then shared with the requesting website.
The following option is triggered:
When you disable this option all of the options return to their default values.
DNS resolution is dominated by latency instead of bandwidth and the time to resolve a host is getting longer now that DNSSEC is being used. This makes DNS lookups a perfect candidate for speculative pre-fetching. The advantage is in the latency improvement; instead of waiting for a hostname lookup when you click on a link, do the lookup while you are reading the page the link is embedded in. The cost of the lookups is small compared to time saved when waiting for the hostname to be resolved after clicking on that link. By keeping DNS prefetching enabled you may gain 1% to 3% speed increase, but this gain is not likely to be noticed. This sounds like a great option! So, what is the problem?
When you go to a web page, Firefox will look at all of the links to all of the sties on that page. Then the browser will ask for the ip address for every one of those hosts. If the owner of the DNS server of the domain, the owner of the DNS server you are querying and anyone listing to the network wanted to profile your browsing habits they would only need to list out your requests by ip. Once the data is correlated they could get a good idea on not only the sites you go to, but also the pages on those sites. Remember that even if the web page you went to is SSL encrypted the DNS requests are not.
The prefetcher does the opposite of its promise. It actually slows down the browser by looking up hundreds of domains a user will not click on. A good example is news.google.com which spawns around 375 DNS lookups. All this dns overhead to save one(1) dns lookup the user actually clicks and requests. In essence, we have traded one perceived performance advantage for an increase in system load, browser speed and network bandwidth.
So, what are the implications to privacy using prefetching? The best case scenario is that this prefetching introduces some noise into any logs made by the DNS server. The worst case scenario is that this enables a finer granularity of information to be inferred from the logs. For example, if a.com/a.html is the only page that has a link to b.com, and a user requests DNS records for both a.com and b.com in a short period of time, we can infer that he visited a.html.
For more information on DNS prefetching and its impact on privacy take a look at the study called, "DNS Prefetching and Its Privacy Implications".
To try to retain some privacy and reduce system load we offer the option to disable DNS prefetching.
The following options are triggered:
When you disable this option all of the options return to their default values.
When you click on a link, the link sends you to the new web page. Firefox requests the new page and will send information to the new server about where you clicked the link from. This information is called the "referer". If you come from a search engine, like Google, Firefox will also send the search parameters you used. For Privacy you may not want any of this information passed to the new server. By enabling this Privacy option the referer will not be sent at all and in the remote server logs there will be only a dash "-" where the referer should be. This is true for all combinations of http(s) to any http(s) sites. To test the referer try a site like WhatsMyReferer.com. Try going to the test site with the referer enabled and disabled to see the difference. Remember to restart Firefox when changing preferences in this add on.
The following option is triggered:
When you disable this option all of the options return to their default values.
Every time Firefox goes to a website the user agent is sent to the remote server. The user agent will include the version of Firefox and general operating system information. There is no real reason a remote web server would need these many details about our computer. For Privacy you may not want any of this data being broadcast to the world as it can be used to vector targeted attacks by malicious web servers or ad networks. By enabling this Privacy option the user agent will be anonymized to a generic string.
For example, the default user agent sent from a 64bit Ubuntu linux machine running Firefox 37 looks like "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0". With this option enabled we anonymize the user agent to the generic string "Mozilla/5.0 (compatible)". This anonymized format is happily accepted by Google and other services as valid. Note that sending no user agent at all or even a non-standard string can break sites which try to dynamically format their pages for certain devices. Our abbreviated user agent string seems to work fine. To test the user agent yourself try a site like WhatsMyOS.com. Try going to the test site with this option enabled and disabled to see the difference. The bottom of the WhatsMyOS test page will show your real user agent string. Remember to restart Firefox when changing preferences in the add on.
Note: some sites may not load correctly if they are checking the browser's user agent for a very specific string. Sites using the useragent for site authentication or access is a very poor security model which is why most sites disabled the User-Agent checks long ago. Turn this option off if you find sites you go to are denying access.
The following option is triggered:
When you disable this option all of the options return to their default values.
This option disables the browser's ability to cycle animated images. An example would be an advertisement or a little icon in someones signature or forum. If you dislike seeing obnoxious ads animating over and over this is a great solution.
Understand that this does not stop flash or movies from playing.
The following option is triggered:
When you disable this value all of the options return to their default values.
A "Tool Tip" is the little box that pops up under the mouse cursor and shows some text about the image you are hovering over. If you find tool tips useless and distracting this option can help.
The following option is triggered:
When you disable this value all of the options return to their default values.
Normally, Firefox will only spell check a text box if that text box is two(2) lines or greater. This option simply enables spell checking on all text boxes. This means when you type something into Google's search box, post a twitter post or anything which is entered on a single line Firefox will spell check the entry. You will see a red wavy line under the misspelled word. Just right click on the word in question and see Firefox's suggestions for the correct spelling.
The following option is triggered:
Lastly, if you want to install dictionaries for more languages go to Mozilla's Dictionaries & Language Packs page.
When you disable this value all of the options return to their default values.
Firefox will internally cache up to 20 hostname to ip address pairs for 60 seconds. This is done to help speed up browsing to some sites. The main problem is if you use Firefox to test servers in a production environment and those hostname to ip address change frequently. It is a pain to have to wait till Firefox clears it's own cache or remembering to clear the cache manually every time you test a new server.
The other problem is many of the busiest sites have significantly more than 20 links to 20 different hostnames so internally caching is really not that helpful.
This option just disables Firefox's internal DNS cache completely and directs Firefox to check an external DNS server. The external DNS server could be your OS if you have that setup or it could be you local LAN DNS server.
If you setup your own DNS caching, validating and resolving server like Unbound or BIND then Firefox will use those directly. We find that querying our private Unbound DNS server is significantly faster than using the internal cache.
If you are using Firefox on Windows then Windows contains a client-side Domain Name System (DNS) cache. If you want to, you can disable this cache by searching on google for "disable windows dns cache". Once Firefox's cache is disable and Windows cache is disable then you should be querying your external LAN DNS server.
You many want to test this option yourself on your network to see if you want to use it.
This option is exactly what the Firefox add-on "DNS Cache" does and basically negates the need to manually clear the DNS cache like what the add-on "Clear Cache Button" does.
The following options are triggered:
When you disable this value all of the options return to their default values.
This simply opens up a tab and loads this help page when the add-on is updated. When changes are made you can read about them here in detail after Firefox is restarted. You can also get to this page using the link at the bottom of the drop down box after clicking the colored URL icon button.
When you disable this value the help page will not open on upgrades.
I have a question, comment or suggestion about the add-on.On the Mozilla Firefox page for the add-on,"Calomel SSL Validation" there is a review box. You are welcome to write a review, grade the add-on and add any addition comments you have concerns about. This is not a bug reporting tool, but should serve this purpose fine. We would be happy to hear about any way to improve the extension.
I notice when I open a blank tab there is a saying in the drop down box.When there is not an active connection in a tab the drop down box does not really do much. So, we put the current version of the addon in the drop down panel.
What can I do about Adobe Flash cookies which are NOT controlled by Firefox ?
If you setup Firefox in "Private Browsing" mode and delete cookies when you shut the browser down, Flash cookies will NOT be deleted. A flash cookie, or Local Shared Object, is a file a website using Adobe products stores on your computer, outside of the control of your browser settings. This is different from a regular cookie. These are associated with Adobe flash which is used by many websites. Unfortunately, they are also used to store tracking information. This data can be accessed by sites who did not originally set them as well as back up data from regular cookies stored by your browser; which should have been deleted. This is a HUGE privacy violation.
In Ubuntu and many Linux distributions, Adobe Flash settings are stored in ~/.adobe and the cookies themselves in ~/.macromedia folders. We suggest symlinking these to /dev/null so anyone trying to write to these folders does not get an error message, but nothing ever gets written to disk.
We use the following commands to link Adobe to /dev/null
Eventually, HTML5 should be able to replace Adobe Flash video and some other Adobe functions. We hope this day comes sooner then later when a company like Adobe does sneaky actions like these.
Finally, we prefer simple solutions, but if you do not want to setup the directories to link to /dev/null then there is a add-on that can help. Take a look at "BetterPrivacy" on the mozilla site. It has this ability to delete these types of Flash 'SuperCookies'.