(at 09:00 GMT Saturday 12th June 2010)
Most reputable, professional, organisations with a pubic website, which ask for personal or financial details etc. use Transport Layer Security (TLS) / Secure Sockets Layer (SSL) encrypted web sessions, especially for web forms which include sensitive data.
This is implemented through the https:// prefix in the address bar or embedded Uniform Resource Locator (URL) web page links in the vast majority of modern web browser software.
The encryption software is built in by default into your web browser and operating system, but for an encrypted session to be established, a Digital Certificate needs to be installed on the web server.
These bind an official web server DNS domain name and and organisation name to a particular asymmetric public encryption key, which then allows your web browser to establish an encrypted session with the web server, which protects that session with a private, symmetric cryptographic algorithm key e.g. AES, 3DES, RC4 etc.
You can create your own Digital Certificate and "self sign" it, but most web browser software will then flash up various warnings and ask you to make "do I really trust this website" decisions, which will certainly scare off any cautious people.
Most reputable organisations fork out some money for a Digital Certificate bought from one of the main Certification Authorities, which at least insist on (usually) only issuing a Digital Certificate to the domain name owners of the particular web server and perhaps running some sort of elementary credit check / company name and address check.
Since these major Certificate Authorities are trusted by default by your web browser software (you can usually choose to remove them from the trusted list, if you can be bothered) no warnings will frighten off potential customers etc, if a current Digital Certificate is in use.
Since such Digital Certificates are bought and renewed usually on an annual or multi-year basis, when they expire, then Invalid Certificate or Expired Certificate warnings automatically appear.
Professional, trustworthy organisations do not let their Digital Certificates expire, they purchase a new Digital Certificate before hand either to be valid from the expiry of the old one, or more usually, with an overlap period, so that they have time to correct any administrative or technical configuration errors with the new Certificate, whilst the old one is still valid.
A new Digital Certificate usually requires the generation or installation of a new Private Encryption Key on each of the Web Servers which it applies to. This may require physical access to the data centre, or at least secure remote control of those servers.
Will WikIleakS.org manage this Digital Certificate rollover properly and professionally ?
Will they replace their obsolete, potentially forgeable RapidSSL MD5 signed Digital certificate with a new one ?
They have until 16:14:01 Greenwich Mean Time today, Saturday 12th June 2010 to do so,
If they do not do this , then their https://secure.wikileaks.org web form, the only secure method of uploading "whistleblower leaks" via their website will be broken, as they seem to have abandoned both Tor Hidden Services and PGP email / file encryption
UPDATE 18:00 GMT
Sadly, we are not surprised that the https://secure.wikileaks.org Digital Certificate has not been properly rolled over and replaced.
The https://secure.wikileaks.org link is still offline since yesterday
There is now no online method of "securely" uploading "whistleblower leak" documents or files to WikiLeakS.org
With Julian Assange reportedly trying to avoid contact with the US authorities, is WikiLeakS.org effectively out of action again ?
Our WikiLeak.org blog postings never seem appear on WikiLeakS.org media monitoring article lists or on their Twitter hype stream.
Now that Wired magazine, which Julian Assange and the others obviously do read, has now linked to us as "careful observers", perhaps we will now be loftily dismissed or insulted via Twitter, like other critics have been.
http://www.wired.com/threatlevel/2010/06/wikileaks-submission/