When using Viscocity to connect to a corporate network or any other openVPN server, you’re probably using certificates with a reasonable lifetime, but sometimes the certificate expire and needs be updated. Replacing the certificate files through the Viscocity interface is quite easy – just edit the connection and replace the certificate files in the appropriate tab.
There is however another little trick, which may need to be applied before the new certificates work. Viscocity offers to save the certificate password in the Keychain and I choose to use this feature, which caused a bit of trouble when updating the certificate. While it ought to – Viscocity does not – clear the password, when the certificate is changed, so to get prompted you need to go into the Keychain access tool and delete the stored password.
Look for an entry looking something like the highlighted line below and delete the occurrence.
Connection debugging tip
Viscocity provides a detailed log, which makes it much easier to debug connection issues. In the OSX Menu bar, right click the Viscocity icon, then choose “Details”. This opens a details window where a the button bar. The button to the right allows you to see a fairly detailed log of what Viscocity is doing, and provides clues on what to fix. In the screenshot below, it’s a wrong certificate password issue (“private-key-password-failure”).
One of the great features of WordPress is the wide variety of plugins available. They often enable a lot of interesting functionality and integrations to other services not native to WordPress itself. Most of these plugins are developed by individuals or small teams independent of the core community – and often not with a keen interest in security, but an exclusive focus on “making stuff work”.
I’ve been using the WordPress “Google AdSense Dashboard” for awhile, and after the recent host of password leaks, I’ve been changing and upgrading password all around. This change lead to expose what I would call a critical password exposure in the plugin and so far caused me to remove the plugin everywhere I’ve installed it.
The issue was the following:
If the password to Google AdSense fails in the plugin, your username and password is displayed in clear-text on screen – in the dashboard when logged into WordPress. Where’s the catastrophic take away – the username and password seems to be stored in clear text (or at least stored by the plugin in a format which can be converted back to clear text), and secondly, apart from storing it somewhat carelessly the plugin even display the information on the login screen – apparently for each and every user.
While surfing the net, you often come across web agencies how promote SSL-certificates (or TLS security) on their products – or their ability to create “secure web applications” with SSL. Most users know HTTPS/SSL/TLS as the little lock, that promises “security” when visiting a page – but what kind of security it actually provides is rarely explained – and far worse often misunderstood.
The while SSL is the popular name (and as it was once known) and HTTPS usually is the way users sees it (as part of a URL in a browser) – the correct name is TLS a short for Transport Layer Security.
The TLS provides point-to-point security between the browser and and server. It makes certain no-one can see the traffic (/data) sent between the two parties. Simply put, it provide a secure tunnel/pipe, where anyone can’t listen in. Almost everyone understand TLS to this point.
Many users however thinks it provides more than this. That TLS provides protection from malware infection, voids dangers of cross-site scripting attacks and other dangers of the web, and TLS does not provide any of the sorts.
While the security it provides is good and solid, it is important to understand the scope and purpose of TLS/SSL, it’s often an important part of the security infrastructure of a web application, but only part of it.