RECENT BLOG NEWS
Or sign up to receive weekly email notifications containing the latest news from wolfSSL.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.
Guest blog, written by Robert Hörr (e-mail: robert (dot) hoerr (at) t-systems (dot) com)
(Security Evaluator of Deutsche Telekom Security GmbH)
My name is Robert Hörr and I am working as a penetration tester at Deutsche Telekom Security GmbH. Pentesting is mostly done on security software, as for instance the wolfSSL TLS library to discover issues like the Heartbleed bug of OpenSSL. I have discovered some issues in the wolfSSL TLS library (see https://www.wolfssl.com/docs/security-vulnerabilities) using my own developed TLS-FAST (Fast Automated Software Testing) framework. In the future my goal is to provide our customers a FAST service to test their software products.
Why are TLS libraries tested?
It is important to check TLS libraries because TLS is one of the most deployed security protocols in the Internet. Typically, there is no client authentication on a standard Internet server by default configuration, to ensure that every Internet user can use it. Hence, any vulnerability in the TLS protocol implementation can be exploited easily. There are many TLS vulnerability entries in the public CVE list and the number is growing constantly.
Which testing approach is used?
The wolfSSL TLS library is a constantly growing project, with more and more functionalities, extensions and TLS versions added to its scope over time. This offers wolfSSL customers maximal flexibility in the use of the wolfSSL TLS library. Because of this growing process, the source code gets more complex. It is hardly possible to check all code paths by a manual source code review. Hence, dynamic automated machine testing must be performed. An efficient way to perform this kind of testing is the code coverage fuzzing approach. This fuzzing variant allows to discover all code paths. The discovering speed depends on the available computing resources. The code paths are checked systematically for memory leaks, buffer overflows, logical issues and so on.
Which tools are used for TLS testing?
Several open source fuzzing tools, which are based on this fuzzing approach, are public available. Some of the most popular ones are AFL, LibFuzzer and HonggFuzz. The community discovered many issues using any of them. Each of these tools has its strengths in certain fuzzing areas, for example HonggFuzz has a higher number of executions per second than the other tools. To benefit from all fuzzers at the same time, I have developed the FAST (Fast Automated Software Testing) framework for TLS libraries, which combines the strengths of several fuzzing tools. Over the time, the following features and approaches have been added to this framework:
- Deterministic runs:
- The entire testing process is deterministic, so that discovered issues can be reproduced easily.
- The testing process is independent from the environment. So that for example the process can be executed on every operating system.
- Realistic use:
- The TLS libraries are used realistically to discover issues occurring in the field. So for example the original source code and the code paths should not be changed.
- All kinds of implementation issues can be discovered by the testing process. For example buffer overflows or memory leaks are detected by the AddressSanitizer.
- Logical issues or vulnerabilities are discovered by specific TLS tests.
- The testing process can be scaled linearly by adding more computation and storage resources.
- Code coverage is used to detect all code paths. If all applicable code paths are identified, the actual testing will start.
- The full testing process runs automatically on a machine. Therefore no manual work is needed anymore.
- The framework can be adapted to another tested software. This adaption to a new software takes some hours or days.
How is the wolfSSL TLS library tested?
The wolfSSL TLS library includes several TLS versions, features, extensions and crypto options. The testing focus was mainly defined on the TLS handshake of TLS versions 1.2, 1.3 and their extensions and features, because the TLS handshake implementations include most of the known TLS vulnerabilities (CVEs) and the other TLS versions are not recommended to use anymore.
Currently I am using the TLS-FAST framework for checking the API functions wolfSSL_accept(…) and wolfSSL_connect(…) of the wolfSSL TLS library master branch. This master branch gets the newest updates first. So the master branch must be tested to discover the newly added issues from the updates and to avoid that these new issues are linked into a stable version.
Most issues I have found (see https://www.wolfssl.com/docs/security-vulnerabilities) are located in the parsing process of the TLS messages client_hello and server_hello. These issues were buffer overflows or uninitialized memory. They could be fixed easily by simply adding a sanity check or a memory initialization. For the sake of completeness, it should also be mentioned that the wolfSSL TLS library source code includes about 521,655 lines of code (without comments and blanks). Hence, it is not easy to avoid issues without fuzzing.
What will be fuzzed in the future?
Currently I am testing the wolfSSL TLS library only, but wolfSSL provides further libraries, like wolfCrypt. These libraries interoperate and make use of each other. For example, the wolfSSL TLS library uses functions from the wolfCrypt library. So the other libraries must be tested, too. In the future, I will develop a new FAST framework for each of them. These new FAST frameworks will have the same features and approaches like the TLS-FAST framework. Over the time, new features will be added to these FAST frameworks.
My goal is to provide our customers a FAST framework as a testing service for their software products. This service detects all issues as quickly as possible.
Contact wolfSSL at firstname.lastname@example.org with questions about the wolfSSL embedded SSL/TLS library, or to get started with wolfSSL in your project! wolfSSL supports TLS 1.3, FIPS 140-2/3, DO-178, and much more!
FIPS 140-2 requires the use of validated cryptography in the security systems implemented by federal agencies to protect sensitive information. The wolfCrypt Module is a comprehensive suite of FIPS Approved algorithms. All key sizes and modes have been implemented to allow flexibility and efficiency.
The National Institute of Standards and Technology (NIST) is sending FIPS cert #2425 into sunset June 2021. For customers who will be impacted, the wolfCrypt Cryptographic Module maintains its #3389 certificate and can be used in conjunction with the wolfSSL embedded SSL/TLS library for full TLS 1.3 client and server support. Upgrade your FIPS cert with wolfSSL to stay afloat and benefit from:
- Algorithm support for TLS 1.3!
- New algorithms such as AES (CBC, GCM, CTR, ECB), CVL, Hash DRBG, DSA, DHE, ECDSA (key generation, sign, verify), HMAC, RSA (key generation, sign, verify), SHA-3, SHA-2, SHA-1, and Triple-DES
- Hardware encryption support for NXP’s Cryptographic Assistance and Assurance Module (CAAM), NXP Memory-Mapped Cryptographic Acceleration Unit (mmCAU), Intel’s AES-NI, and more
- Support for secure elements and TPM’s
- Interoperability with wolfBoot, wolfSSH, and wolfTPM
- Integration support for third party libraries such as strongswan, nginx, python and more
Contact us to upgrade to FIPS cert #3389 at email@example.com.
Learn more about wolfSSL support for FIPS cert #3389: https://www.wolfssl.com/wolfcrypt-fips-certificate-3389-3/
For a list of supported Operating Environments for wolfCrypt FIPS, check our FIPS page: https://www.wolfssl.com/license/fips/
Our FIPS Story
wolfSSL is currently the leader in embedded FIPS certificates. We have a long history in FIPS starting with wolfCrypt FIPS 140-2 Level 1 Certificate #2425 as well as wolfCrypt v4 FIPS 140-2 Level 1 Certificate #3389. wolfSSL partners with FIPS experts KeyPair to bring you FIPS consulting services, and high assurance along each step of your FIPS certification process. Additionally, wolfSSL will be the first implementation of FIPS 140-3.
wolfSSL also provides support for a wolfCrypt FIPS Ready version of the library! wolfCrypt FIPS Ready is our FIPS enabled cryptography layer code included in the wolfSSL source tree that you can enable and build. You do not get a FIPS certificate, you are not FIPS approved, but you will be FIPS Ready. FIPS Ready means that you have included the FIPS code into your build and that you are operating according to the FIPS enforced best practices of default entry point, and power on self test.
wolfCrypt FIPS Ready can be downloaded from the wolfSSL download page located here: https://www.wolfssl.com/download/. More information on getting set up with wolfCrypt FIPS Ready can be found in our FIPS Ready User guide here: https://www.wolfssl.com/docs/fips-ready-user-guide/
The wolfSSL team is happy to announce support for the latest version of Apache httpd, 2.4.46, with both our standard and FIPS-compliant code. In addition to building wolfSSL with
--enable-apachehttpd, users will also need to add
To support this latest version, we have added new OpenSSL compatibility functions to wolfSSL, updated our Apache httpd documentation, and provided patch code for httpd to make it play with wolfSSL. Please contact us for access to our Apache patch files. Importantly, Apache with wolfSSL also supports the latest and greatest TLS version, TLS 1.3.
Big news for Linux kernel module developers with crypto requirements! wolfCrypt and wolfSSL are now loadable as modules in the Linux kernel, providing the entire libwolfssl API natively to other kernel modules. For the first time on Linux, the entire TLS protocol stack can be loaded as a module, allowing fully kernel-resident TLS/DTLS endpoints with in-kernel handshaking.
Configuration and building is turnkey via the new
--enable-linuxkm option, and can optionally be configured for cryptographic self-test at load time (POST). As with library builds, the kernel module can be configured in detail to meet application requirements, while staying within target capabilities and limitations. In particular, developers can opt to link in only the wolfCrypt suite of low level cryptographic algorithms, or can include the full TLS protocol stack with TLS 1.3 support. When configured for AES-NI acceleration, the module delivers AES256-GCM encrypt/decrypt at better than 1 byte per cycle.
The kernel module configuration leverages our new function-complete “single precision” bignum implementation, featuring state of the art performance and side channel attack immunity. Watch this space — we’ll have a lot more to say about the many advantages of our new bignum implementation!
As a proof of concept, we have retargeted the Linux WireGuard kernel module to use wolfCrypt for all cryptography, with full interoperability, and will soon be sharing more on those results. Kernel module builds of libwolfssl will be supported in wolfSSL release 4.6, and are available immediately in our mainline github repository, supporting the 3.x, 4.x, and 5.x Linux version lines on x86-64.
For more information about wolfSSL, contact us at firstname.lastname@example.org.
wolfSSL has recently added support for Nginx version 1.7.7. Nginx is a high performance HTTP server and reverse proxy. Just like wolfSSL, Nginx is an open source project serving millions of users around the world. Expanding Nginx support gives users the power to choose their preferred cryptographic and SSL/TLS library. wolfSSL is very customizable, which allows its users to configure it exactly to their exact needs.
Matched with the corresponding patch file, wolfSSL users can use the
--enable-nginx configure option to compile wolfSSL with Nginx support. wolfSSL currently has support for the following versions of Nginx:
- Nginx 1.17.5
- Nginx 1.16.1
- Nginx 1.15.0
- Nginx 1.14.0
- Nginx 1.13.12
- Nginx 1.13.8
- Nginx 1.13.2
- Nginx 1.13.0
- Nginx 1.12.2
- Nginx 1.12.1
- Nginx 1.12.0
- Nginx 1.11.13
- Nginx 1.11.10
- Nginx 1.11.7
- Nginx 1.10.3
- Nginx 1.7.7
With more being added all the time. For more information on wolfSSL Nginx support, contact email@example.com. The wolfSSL embedded SSL/TLS library includes support for TLS 1.3, has been FIPS 140-2/3 validated, and also can use a DO-178 certified version of wolfCrypt if needed.
wolfSSL is up and running and tested on Apple’s new A12Z platform, and with the right options it is blazing fast! The key options that we benchmarked include our out of the box defaults vs some key optimizations described below. Some notes to help you decipher these benchmarks:
- SP is Single Precision Math. It is a wolfSSL developed math library that is extremely well optimized for ARM environments and cryptographic math calculations.
- SP ASM is the assembly component of the SP math library.
- ARMASM is the assembly code functionality provided by ARM. As many of our savvy readers know, we have the best support for ARMv8 cryptography extensions, and they work great!
- MB/Sec is the number of megabytes of data that you can encrypt or decrypt per second. If you have big files to encrypt/decrypt, then you will really enjoy the power of SP math and the ARMv8 cryptography extensions!
- This is our first pass of optimizations for these benchmarks. We’ll do more, and we expect that a few more passes of optimizations will yield 20% to 40% more performance on any given cipher.
See below for more details!
(Default Options, MB/sec, higher is faster)
(SP + SP ASM + ARM ASM, MB/sec, higher is faster))
(Default Options, ms/op, lower is faster)
(SP + SP ASM + ARM ASM, ms/op, lower is faster)
|RSA 2048 Pub||0.612||0.022|
|RSA 2048 Priv||6.274||0.722|
|DH 2048 Key Gen||1.339||0.338|
|DH 2048 Key Agree||2.008||0.338|
|ECC 256 Key Gen||2.554||0.022|
|ECC 256 Key Agree||2.54||0.061|
To enable SP + SP ASM + ARM ASM and achieve maximum performance on Apple’s A12Z, pass in the following options to configure:
./configure --host=aarch64-apple-darwin --enable-sp --enable-sp-asm --enable-armasm
Note that the host flag is only required if the host is not detected as aarch64 by default. Check config.log after running configure to confirm this.
If you have questions on these benchmarks, or if you would like some support to help replicate them on your system, let us know at facts at wolfSSL .com or give us a call!
Both SSL and TLS are terms that refer to protocols designed to secure communications over the Internet. They stand for Secure Socket Layer and Transport Layer Security, respectively.
SSL was designed by Netscape Communications and implemented in their browsers; several vulnerabilities were discovered in SSL, and the version was upgraded to continue revisions in terms of security. However, with the discovery of vulnerabilities due to the POODLE attack, the last specification, SSL 3.0 was also discontinued by the Internet Engineering Task Force (IETF) in 2015. After this, SSL should not be used.
In 1996, before SSL was decommissioned, the IETF started to develop a specification for TLS, and TLS continued to be revised to include countermeasures against new attack methods discovered one after another, with the now widely used TLS 1.2 being established in 2008. The most current standard is TLS 1.3, which was published in August 2018.
SSL and TLS have different names, but the purpose and role are the same, and the two are often used interchangeably. wolfSSL also still uses “SSL” in its company and product names.
Differences in Specifications
Both SSL and TLS provide a means to encrypt and exchange data on the communication path (usually TCP/IP). Major 3 processes are:
- Authenticate the other party to communicate
- Determine a method and key to encrypt communication data
- Encrypt and decrypt communication data
It is said that the difference between the first version of TLS, TLS1.0, and the last version of SSL, SSL3.0, in terms of this feature, was minimal. Therefore, rather than knowing this boundary, it is more meaningful to know how the current TLS1.3 specification has changed.
What is the difference between TLS 1.3 and before?
The following specification changes have been made:
* Sifted through encryption algorithms and change encryption suite notation
* Reduced and sped up packet round trips by reorganizing handshake messages
* Encryption begins earlier in the handshake
Cryptographic suites previously had hundreds of definitions. The number of algorithms has been reduced to 5 by removing the algorithms that are no longer used, limiting them to essential algorithms, and organizing the encryption suite notation. Only the temporary key Diffie-Hellmann remained as the key exchange algorithm. Packet round-trip during handshaking is minimized to one round-trip. Also, encryption is performed in the middle of the handshake. The TLS 1.3 specification is designed to improve both security and communication speed.
Both SSL and TLS are still used interchangeably to refer to handshakes performed on clients and servers. However, SSL as a specification term is now a specification of the past and is not used in actual products. As of 2020, even servers that use TLS 1.1 will receive security warnings from typical browsers. The difference between SSL and TLS will only be questioned when looking back on history.
What’s important as a TLS user is to be aware of the differences between TLS 1.3 and the current mainstream TLS 1.2.
Contact wolfSSL at firstname.lastname@example.org to learn more about how wolfSSL can help secure your product or project today!
A Cipher Suite is a set of cryptographic instructions or algorithms that helps secure network connections through Transport Layer Security(TLS)/Secure Socket Layer (SSL). It helps determine how your web server will communicate secure data over HTTPS, and makes sure to secure the communications between client and server.
To start a HTTPS connect, the web server and the client perform what is a SSL handshake. The SSL handshake is a process that leverages various cryptographic functions to achieve a HTTPS connection. During the handshake, the two parties agree on a cipher suite, which is then used to secure the HTTPS connection.
During the handshake, the cipher suite typically uses these algorithms;
- Key Exchange Algorithm
- A method by which keys can be exchanged
- Ex: RSA, DH, ECDH, ECDHE, PSK
- Bulk Encryption Algorithm
- A method by which symmetric key algorithms will be used to encrypt data
- Ex: AES, 3DES, CAMELLIA, ARIA
- Authentication Algorithm
- A method that dictates how server authentication and client authentication is implemented
- Ex: RSA, DSA, ECDSA
- Message Authentication Code (MAC) Algorithm
- A method that determines which connections to use for data integrity checks
- Ex: SHA, MD5, POLY1305
- Key Exchange Algorithm
These ciphers are used at various points of the connection to perform authentication, key generation and exchange, and a checksum to ensure integrity. The client and web server will start by deciding which specific algorithms to use in the cipher suite.
A typical Cipher Suite contains 1 key exchange, 1 bulk encryption, 1 authentication, and 1 MAC algorithm. C
Here is an example from Security Boulevard
“Starting from left to right, ECDHE determines that during the handshake the keys will be exchanged via ephemeral Elliptic Curve Diffie Hellman (ECDHE). ECDSA or Elliptic Curve Digital Signature Algorithm is the authentication algorithm. AES128-GCM is the bulk encryption algorithm: AES running Galois Counter Mode with 128-bit key size. Finally, SHA-256 is the hashing algorithm.”
Why Cipher Suites are Important
Cipher suites are important for ensuring the security, compatibility and performance of the HTTPS connections. The cipher suite is like a recipe that dictates which algorithms to use to make secure and reliable connections.
- Security – The security level of the HTTPS traffic (or the safety of both server and client data) depends on the cipher suites the web server uses
- Compatibility – The compatibility of the HTTPS traffic (or who has access to errors, warnings etc) depends on the cipher suites the web server uses
- Performance – The performance of the HTTPS traffic (or the page speed) depends on the cipher suites the web server uses.
wolfSSL and Cipher Suites
wolfSSL is modular. We’ve got two key modules: wolfSSL handles all TLS/SSL needs while wolfCrypt handles all cryptographic needs including block ciphers, stream ciphers, message digests, hashing, public key cryptography, certificates, and various helper utilities.
The wolfCrypt cryptography engine is a lightweight crypto library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments – primarily because of its small size, speed, and feature set. It is commonly used in standard operating environments as well because of its royalty-free pricing and excellent cross platform support. wolfCrypt supports the most popular algorithms and ciphers as well as progressive ones such as HC-128, RABBIT, and NTRU. wolfCrypt is stable, production-ready, and backed by our excellent team of security experts.
A complete description of wolfCrypt and our ciphers is available here: https://www.wolfssl.com/docs/wolfssl-manual/ch10/.
Cipher suites are an integral part of how websites function over HTTPS. They are a combination of ciphers used during the SSL/TLS handshake to determine the security settings of an HTTPS connection. Choosing and maintaining the appropriate cipher suites, both in the web server and the client, is important to ensure the security, performance, and compatibility of your HTTPS communications.
For information regarding the use of cipher suites or general inquiries about wolfSSL’s embedded SSL/TLS library contact us at email@example.com!
wolfSSL is very proud to let our FIPS community know that wolfCrypt has received its’ first two consolidated ACVP vector certificates!
Both of these consolidated certificates were for embedded operating environments (OEs’) and wolfSSL will soon be working on adding a Linux 4.4 on ARM OE, CMSIS-RTOS on EFM32 OE, WINCE on ARM OE and more!
As many in the FIPS world are aware NIST retired CAVP (Cryptogrphic Algorithm Validation Protocol) testing on June 30th of 2020, permanently replacing CAVP with ACVP (Automated Cryptographic Validation Protocol), also referred to as ACVTS (Automated Cryptographic Validation Test System).
In order to prepare for this transition NIST offered a “demo server” that Vendors like wolfSSL and FIPS Labs could utilize in standup of the new protocol. Once the transition was completed NIST also setup “production servers” which only FIPS Labs with a trusted certificate issued by NIST can connect to. Production Vectors passing are now the gateway to Algorithm Certification (IE certs like the ones wolfSSL just received!).
Algorithm Certification is a prerequisite to CMVP FIPS 140-2 (and 140-3) validations. This design keeps in place the need for a FIPS lab to achieve algorithm certification but it now allows for Vendors such as wolfSSL to pre-test in advance of requesting production vectors for certification!
The ACVP client wolfSSL has developed can do several things:
- Connect to the demo server, request test vectors for 1 (or many) algorithms, process them, and return the responses ultimately receiving either a “pass” or “fail” result.
- Support for testing on full Operating System such as Linux/Windows/Unix
- Support for testing on embedded Operating Environments (Yes even those that are barely above bare-metal)!
- Process JSON files received from a FIPS lab containing production vectors and write out JSON response files for returning to a FIPS lab.
- Support for testing on full Operating System such as Linux/Windows/Unix
- Support for testing on embedded Operating Environments (even those that are barely above bare-metal)!
- The wolfSSL ACVP client also has some local known-answer tests it can run to check algorithms without an RNG component IE most bulk encryption algorithms without an integrity check, and hash algorithms. Bulk encryption algorithms with an integrity check, public key algorithms, and the DRBG can only be sanity-checked against the demo server as the outputs are random and can not be simply diffed with a static known-answer test file.
Users who may want to prepare in advance for the possibility of doing a FIPS validation could use the wolfSSL proprietary ACVP client to test their implementations are ready before pulling the trigger on a FIPS effort with a FIPS lab! If you have any questions or are interested in hearing more about the wolfSSL ACVP client or having wolfSSL validate an Operating Environment so that you can win those deals with customers that need a FIPS validated software module, please contact us at firstname.lastname@example.org or email@example.com anytime!
For information regarding the use of cipher suites or general inquiries about wolfSSL’s embedded SSL/TLS library contact us at firstname.lastname@example.org!
Hi webinar friends!
Join us for our upcoming webinar on December 16th, 2020 with wolfSSL Engineering Manager, Chris Conlon. This webinar will provide attendees with the basics and best practices needed to get started using the wolfSSL TLS library in products and projects into 2021! Topics will include a brief overview of TLS 1.3, wolfSSL package structure, how to build wolfSSL, running the wolfCrypt cryptography test and benchmark applications, wolfSSL basic API usage, tips on debugging, and more! Bring your questions for the Q&A session to follow!
When: Dec 16, 2020 09:00 AM Pacific Time (US and Canada)
Topic: Webinar: Get Started in 2021 with wolfSSL
Register in advance for this webinar:
After registering, you will receive a confirmation email containing information about joining the webinar.
See you there!
- January 2021 (5)
- December 2020 (21)
- November 2020 (14)
- October 2020 (7)
- September 2020 (22)
- August 2020 (11)
- July 2020 (8)
- June 2020 (14)
- May 2020 (15)
- April 2020 (14)
- March 2020 (4)
- February 2020 (24)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (24)
- August 2019 (21)
- July 2019 (8)
- June 2019 (13)
- May 2019 (35)
- April 2019 (31)
- March 2019 (20)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (10)
- October 2018 (18)
- September 2018 (18)
- August 2018 (8)
- July 2018 (15)
- June 2018 (29)
- May 2018 (15)
- April 2018 (11)
- March 2018 (19)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (7)
- September 2017 (8)
- August 2017 (6)
- July 2017 (11)
- June 2017 (8)
- May 2017 (10)
- April 2017 (5)
- March 2017 (7)
- February 2017 (1)
- January 2017 (8)
- December 2016 (3)
- November 2016 (2)
- October 2016 (18)
- September 2016 (8)
- August 2016 (5)
- July 2016 (4)
- June 2016 (10)
- May 2016 (4)
- April 2016 (5)
- March 2016 (4)
- February 2016 (12)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (6)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (13)
- January 2015 (6)
- December 2014 (7)
- November 2014 (3)
- October 2014 (2)
- September 2014 (11)
- August 2014 (6)
- July 2014 (9)
- June 2014 (11)
- May 2014 (11)
- April 2014 (9)
- March 2014 (3)
- February 2014 (3)
- January 2014 (5)
- December 2013 (9)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (8)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (9)
- December 2012 (13)
- November 2012 (5)
- October 2012 (7)
- September 2012 (4)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (5)
- April 2012 (7)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (6)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (8)
- May 2011 (12)
- April 2011 (4)
- March 2011 (12)
- February 2011 (8)
- January 2011 (13)
- December 2010 (17)
- November 2010 (12)
- October 2010 (14)
- September 2010 (11)
- August 2010 (20)
- July 2010 (14)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)