MasterCard SecureCode: Just say no.

Sometime the timing is just too perfect.

Yesterday I was trying to book a flight on Brussel Airlines and when I was trying to pay via credit card, they insisted on an on-the-fly enrollment to MasterCard SecureCode. I refused and booked via the AMEX Business Service.

Today a security analysis of the whole scheme was published by British scientists, confirming my reservations.

Money quotes:

“Merchants who use it push liability for fraud back to banks, who in turn push it on to cardholders.”

“So this is yet another case where security economics trumps security engineering, but in a predatory way that leaves cardholders less secure.”

Microsoft Security Essentials

I can understand that they want to have a look at unknown (to them) software. But this?

I can’t be the first one to actually deploy the update from Adobe which finally fixed the bugs known since December.

Free SSL/TLS certificates

CAcert has tried for some time to provide free X.509 certificates based on automatic checks and a web of trust. They never managed to get the root certificate included in the default installations of the major browsers. As I read it, they’ve given up on Mozilla for now.

Aaron forwarded me a link to a blog post by StartCom where they announce that their CA will be included in IE soon. As they are already recognized by Mozilla and Safari, their certs are pretty much as good as any other commercial x.509 cert for servers.

In that respect, they are not unique, you can buy commercial grade certs from various sources, the most popular being Thawte, Equifax, Usertrust, Comodo, and Verisign.

What makes StartCom special is the fact that they give away free certificates similar to what CAcert is doing. Their enrollment at is pretty much straight forward and getting certificates (both by uploading CSRs or by letting them generate a key) is painless.

Furthermore, they impressed me by:

  • Adding as a valid domain suffix within a few hour after I mailed them.
  • Checking the server for which you requested a cert and giving you hints if you made a configuration mistake.


Crypt::OpenSSL:X509 and UTF-8 strings

Bumped to top due to updates.

For my current project I look at a lot of X.509 certificates using Dan Sully’s Crypt::OpenSSL:X509 Perl module. I’m not using the version from CPAN, but his current codebase straight from his git repository.

While trying to store information about certs in a PostgreSQL DB which is set to UTF-8 strings, I encountered errors. Some debugging later I found that some of the certs had Umlauts in the subject field. The XS code from Crypt::OpenSSL:X509 wasn’t UTF-8 aware, causing automatic down-conversion to ISO-8859-1, which produced illegal byte sequence when parsed as UTF-8.

After some cursing and debugging I came up with this patch:

--- ../dsully-perl-crypt-openssl-x509/X509.xs 2009-03-06 22:22:44.000000000 +0100
+++ X509.xs 2009-08-17 14:46:00.000000000 +0200
@@ -73,6 +73,15 @@
return sv;

+static SV* sv_bio_utf8_on(BIO *bio) {
+ SV* sv;
+ sv = (SV *)BIO_get_callback_arg(bio);
+ SvUTF8_on(sv);
+ return sv;
static void sv_bio_error(BIO *bio) {

@@ -293,8 +302,10 @@
name = X509_get_issuer_name(x509);

+ /* this need not be pure ascii, try to get a native perl character string with utf8 */
+ sv_bio_utf8_on(bio);
/* this is prefered over X509_NAME_oneline() */
- X509_NAME_print_ex(bio, name, 0, XN_FLAG_SEP_CPLUS_SPC);

} else if (ix == 3) {

@@ -799,7 +810,8 @@
n = OBJ_nid2sn(nid);
BIO_printf(bio, "%s=", n);
- ASN1_STRING_print(bio, X509_NAME_ENTRY_get_data(name_entry));
+ sv_bio_utf8_on(bio);
+ ASN1_STRING_print_ex(bio, X509_NAME_ENTRY_get_data(name_entry),ASN1_STRFLGS_UTF8_CONVERT & ~ASN1_STRFLGS_ESC_MSB);
RETVAL = sv_bio_final(bio);


Basically, this just tells the openssl library to output UTF-8 and the perl core that the new strings are encoded in UTF-8.

This might be overkill in the cases where it’s not actually needed, but it should do no harm.

Update: My patch is now in the git repository.

Update2: Life is not that easy. Looking at more X.509 certs in the wild shows that openssl does not check whether it returns a valid UTF8 string. So stay tuned for additional patches in Dan’s git repository.

Update3: My patches are now integrated in the git version.

FUD, the Microsoft way

Dear Microsoft,

we all know that the “Fear, Uncertainty, and Doubt”-strategy worked quite well against Linux and other threats to your Monopoly business. By why do you apply the same tactic towards a Windows user that simply wants to open a zip-file?


(Translation: “This page contains an unspecified potential security risk. Do you want to continue?”)

What do you think a user should do with that information?