The release of the beta
PGP v9.7 a couple of weeks ago, made me kinda curious if I had to pay for the new update. I bought v9.0 officially, and every update 'swallowed' my old license info. And what happend today, when I installed the newly released full version of
PGP 9.7 Desktop... It swallowed my old license.
B.t.w. the original purchase was for the Windows version of PGP, but the license also works on the OSX version of the software (it always did). So it's not necessary to buy a new license when you switch platforms.
There is a downside though; It's not possible to download a full version for the license holders. You need to download the
30-day trail version. And you'll only get it when using a valid e-mail address.
In the old days they had some restriction on how many times (and in what time frame) you used an e-mail address.
Major bummer: the sign and encrypt buttons are no longer available in the Apple mail.app. So you need to use the builtin PGP proxy. So basically, there is no way of manipulating single messages (other than using the clipboard). There is no need for me to sign every mail I send, nor is there the necessity of encrypting every mail I send to a certain person.
Since the upgrade to OSX Leopard, I've not been able to use PGP, since it simple won't work. Yesterday I received an e-mail that the
public beta of PGP 9.7 has been released (for Windows and OSX). This one does work on Leopard (until December this year though), so I guess that I need to BUY myself yet another version of PGP.
I found one 'bug' in the meantime; I seem to be missing the encrypt and sign buttons in the OSX Mail app. Or I might be missing something? I don't want to use the PGP service which signs or encrypts everything. I want to sign and/or encrypt when I want to, and not when an app tells me to.
Every once in a lifetime, a virus/trojan or wahtever for Mac OSX raises it's 'ugly' head. And now we got a
Trojan. Infection occurs through porn websites :-P, and it promises a codec with which you can view the x-rated content on the website(s). I guess that there's a sex-starved market out there.
As you might have guesed, the trojan isn't exactly what it promises to be. It modifies your DNS settings, which are almost undetectable (for regular users). The result is that you might get rerouted to other sites than you originally intended. Since 'they' control the DNS, you might be typing your usernames and passwords for eBay on a site that's not really eBay.
There are way of
detecting and removig the darn thing.
Oke, it seems that UPC has already implemented the so-called child pornography filter. There's no fancy filtering software. They are using their own DNS servers to
re-route traffic. This means that when your using other DNS servers (e.g. openDNS), a modified hosts file, or just browse to the filtered server based on the IP address you'll be just fine.
As I've
mentioned before; with casual browsing you won't end up on child porn websites. Only if you want to find it you'll probably end up getting it. So a awefully simple DNS protection won't stop the real perverts. It's just another false sense of safety.
Somehow, people are directed to my website by queries which contain the following key-words; '
remove', '
certificate', and '
e61'. So, here's a quick certificate uninstall guide:
Menu -> Tools -> Settings -> Security Settings -> Certif. management -> Scroll down to the certificate you wish to delete -> Options -> Delete -> Confirm Delete -> Yes.
It's not that hard :)
(the 'guide' is written for the e61
i, but I doubt if it's much different on the e61)
A while back, I was asked if it's possible to fake a VeriSign issued SSL certificate. In theory, this is possible (if you have like unlimited resources), but on the practical side, it's impossible. It is possible however to create a CA which resembles the VeriSign root up to some level.
Everything, apart to some 'details', can be forged. Name, serial number, timestamps, additional fields etc., can be created by OpenSSL and a special crafted config file. It's just finding out how to do it. The tough (and this is a definite understatement) part is the thumbprint, and the public key.
The public key is generated by cryptographic algorithme (along with the private key), and it's impossible to 'regenerate' this. But for the casual user, this is not a problem. For a normal user it's pretty hard to tell the original from the fake CA certificate, since only details are different. Also, these differences are unreadable pieces of hexadecimal strings.
So all you have to do is to persuade the user to trust the new (and improved) VeriSign CA, and every site he visits may be fraudulent (and probably is).
The following sections contain the real certificate from VeriSign, and the fake one. Now you figure out which one is the real one.
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
02:ad:66:7e:4e:45:fe:5e:57:6f:3c:98:19:5e:dd:c0
Signature Algorithm: md2WithRSAEncryption
Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Validity
Not Before: Nov 9 01:00:00 1994 GMT
Not After : Jan 8 01:00:00 2010 GMT
Subject: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1000 bit)
Modulus (1000 bit):
00:b8:93:ae:c9:5e:c7:8a:9e:97:c7:c3:32:00:73:
45:54:03:db:29:e2:13:4b:7b:78:6e:57:69:b3:c8:
77:a4:a7:48:40:51:99:1b:86:9f:f2:e7:8d:34:40:
fc:99:91:ac:ed:2e:07:7b:da:f6:97:b3:e7:63:2c:
7c:14:c4:8a:61:8f:e4:96:02:40:40:e4:ba:9a:bb:
6a:cb:d9:75:78:00:b7:5f:b3:ca:1b:a8:1f:6b:5b:
44:e3:65:04:72:98:55:5c:fb:e2:2d:bc:46:eb:c7:
44:78:5c:bf:9a:b4:a3:19:a5:d9:17:47:87:bb:73:
12:60:b9:77:18:59
Exponent: 65537 (0x10001)
Signature Algorithm: md2WithRSAEncryption
61:29:b8:7b:55:3b:c6:c7:7c:ed:86:73:b8:30:4a:02:c0:93:
79:06:83:39:f2:9c:9e:40:ca:42:e6:7f:12:e2:7c:22:d3:2b:
d6:8f:a7:d9:a4:93:20:09:9a:6b:26:71:65:bb:ff:dc:70:fb:
d9:5c:a2:34:c6:88:00:ec:51:8a:65:75:53:d4:18:a3:38:f5:
d3:61:14:7b:8f:e4:d2:b3:fe:39:45:7a:4d:ec:f5:35:61:d7:
22:9a:2c:1a:c8:d2:f7:d1:55:4d:02:83:cc:f0:fc:5c:32:a9:
49:d3:d2:2c:5a:c9:b8:9f:b5:d7:7f:3a:9a:b5:d8:55:9d
And the second CA certificate
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
02:ad:66:7e:4e:45:fe:5e:57:6f:3c:98:19:5e:dd:c0
Signature Algorithm: md2WithRSAEncryption
Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Validity
Not Before: Nov 9 00:00:00 1994 GMT
Not After : Jan 7 23:59:59 2010 GMT
Subject: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1000 bit)
Modulus (1000 bit):
00:92:ce:7a:c1:ae:83:3e:5a:aa:89:83:57:ac:25:
01:76:0c:ad:ae:8e:2c:37:ce:eb:35:78:64:54:03:
e5:84:40:51:c9:bf:8f:08:e2:8a:82:08:d2:16:86:
37:55:e9:b1:21:02:ad:76:68:81:9a:05:a2:4b:c9:
4b:25:66:22:56:6c:88:07:8f:f7:81:59:6d:84:07:
65:70:13:71:76:3e:9b:77:4c:e3:50:89:56:98:48:
b9:1d:a7:29:1a:13:2e:4a:11:59:9c:1e:15:d5:49:
54:2c:73:3a:69:82:b1:97:39:9c:6d:70:67:48:e5:
dd:2d:d6:c8:1e:7b
Exponent: 65537 (0x10001)
Signature Algorithm: md2WithRSAEncryption
65:dd:7e:e1:b2:ec:b0:e2:3a:e0:ec:71:46:9a:19:11:b8:d3:
c7:a0:b4:03:40:26:02:3e:09:9c:e1:12:b3:d1:5a:f6:37:a5:
b7:61:03:b6:5b:16:69:3b:c6:44:08:0c:88:53:0c:6b:97:49:
c7:3e:35:dc:6c:b9:bb:aa:df:5c:bb:3a:2f:93:60:b6:a9:4b:
4d:f2:20:f7:cd:5f:7f:64:7b:8e:dc:00:5c:d7:fa:77:ca:39:
16:59:6f:0e:ea:d3:b5:83:7f:4d:4d:42:56:76:b4:c9:5f:04:
f8:38:f8:eb:d2:5f:75:5f:cd:7b:fc:e5:8e:80:7c:fc:50
After creating the CA, I made the SSL certificate (some data has been obscured).
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
1a:b6:68:61:a3:c7:c5:ca:a0:b8:4f:09:c1:97:0e:f4
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Validity
Not Before: Apr 18 15:17:43 2007 GMT
Not After : Apr 17 15:17:43 2008 GMT
Subject: C=NL, ST=Noord-Holland, L=Amsterdam, O=###########., OU=#####, OU=Terms of use at www.verisign.com/rpa (c)00, CN=www.#######.nl
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b5:b7:78:80:6f:a9:3d:d0:d8:99:8e:0c:d3:34:
f2:95:d5:1b:a4:30:44:45:6c:11:71:9b:dc:ae:b7:
3c:1e:0a:5b:81:2d:bd:e6:be:34:cb:7c:e2:de:5f:
20:1f:df:0d:36:ad:83:74:64:b7:52:34:10:f0:bd:
72:09:cf:31:84:77:81:c1:01:16:1d:a5:e9:58:27:
8f:f6:ea:20:15:04:e6:b9:40:d0:16:3f:b9:f3:cb:
06:75:9c:2c:93:d1:55:6e:04:f0:e1:43:6b:53:16:
39:ee:b3:84:62:02:eb:f8:f0:df:74:f4:da:6e:3a:
8a:6b:4a:ab:be:c1:16:9e:d3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 CRL Distribution Points:
URI:http://crl.verisign.com/RSASecureServer.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.23.3
CPS: https://www.verisign.com/rpa;
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Authority Information Access:
OCSP - URI:http://ocsp.verisign.com
1.3.6.1.5.5.7.1.12:
0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
Signature Algorithm: sha1WithRSAEncryption
87:d1:47:c7:ea:59:18:9c:8d:e6:17:53:9c:76:d4:fb:bb:ce:
ab:ab:3f:8a:a6:74:98:67:86:53:39:79:98:62:89:e5:07:27:
73:db:65:9f:10:8c:51:6e:ca:bc:cb:25:46:49:49:8f:0c:b4:
2c:f8:3b:47:95:c2:ba:8c:5e:d8:54:52:83:d5:4d:ed:b2:95:
0b:62:13:1e:9a:61:7c:97:b7:f9:02:52:7a:4f:7a:c6:19:f3:
80:3a:99:6e:27:5b:b2:b8:80:c1:43:d1:b9:0b:9f:02:26:9c:
50:39:a1:18:82:cd:cd:89:dd:ca:5e:e1:52:02:ab:bf:b1
The second CA is the real thing. The first one is the fake CA.
So all you have to do is to persuade the user to trust the new (and improved) VeriSign CA, and every site he visits may be fraudulent (and probably is). Or just infect him/her with a trojan to insert the CA for you.
The 'fun' part is that if you should replace the actual (original) VeriSign CA in your crypto store you get warnings/error messages which aren't very clear. The OS/Browser tries to 'tie' the SSL certificate to the CA, but not everything seems to add up :).
First there were wireless networks, then there was WEP. WEP was the protective layer for wireless, so that your data was (kinda) secure when it traveled through the air. This layer was compromised rather quick, so alternatives were needed.
The initial alternative was WPA. This new layer of protection was a lot stronger (there still isn't a way of hacking this quickly). Downside was that it took a while to become a standard, so every vendor was free to use it as they saw fit. This could result into incompatibility issues when you used different vendors in your wireless environment.
The final WPA standard became WPA2, and was to overcome the incompatibility issues with the earlier WPA.... NOT!!!
Most consumer wireless products in my vicinity just won't connect properly using WPA2 (with either AES or TKIP). The only thing that keeps working is WPA. When connecting to a wireless network which is protected with WPA2, everything seems to go fine, but when you want to transfer data, nothing happens. Also, the wireless base station doesn't show any association with the client.
What is wrong with this picture? Does this mean that there are also different implementations of WPA2 among vendors?
A quick WPA2 configuration with a 32 character (or 16 character) WPA2-PSK key just won't work, while the client devices all support at least WPA2-PSK with TKIP.
Perhaps you don't, but your computer does!
At this moment there are over a hundred Trusted Root Certifications Authorities in your browser or Operating System. Many of those don't mean anything to me.
When a Trusted Root Certification Authority is available in your browser or OS, you don't get any questions/pop-up that your entering a secured Internet connection. This means that the certificate was issued by someone trustworthy. Who decides who or what company is trustworthy?
I know most of the commercial SSL vendors like
VeriSign,
Thawte,
Comodo,
Equifax,
Entrust, and
Cybertrust. Those are the companies which sell most of the SSL certificates used on the Internet. But I haven't heard of
Kozjegyzoi Tanusitvanykiado or IPS Seguridad. So do I want to trust certificates issued by them?
It would be nice if the browser had an extra message box (yes, another message box :-) ) to verify with the user if the CA should be trusted from this point on. This way the (pro-)user gets to decide if he wants to trust the CA (without the trouble of manually verifying the CA details on the CA website), and the basic user may rely on the recommendation from the OS/browser.
This way I can decide for myself if I want to trust some post-office in Japan or Germany.
Last week, I recieved my new Nokia E61i. As soon as I tried to connect to my own IMAP server (over SSL/TLS) is started nagging about the (selfsigned) SSL certificate.
The E61 has a certificate store, so I should be able to add other Root CA's to this store, but this is where the trouble began.
The manual has a chapter on certificates, but it lacks a working explanation on "how to import third party root CA's". On my old iPaq, it was simply upload a DER encoded certificate, click on it, and it would install. Well this doesn't work on the E61 (and many other Symbian-based) phones. Just 'google', and you'll find lot's of people with similar problems...
The working solution I found uses a website from which you download the certificate with the phone, but there is a catch; you need to add a MIME-type to the website containing the certificate (hence the admin rights).
The last couple of days were all about the leaked key for decrypting HD-DVD movies. This made me curious about the technology, so I headed to the
AACS LA website.
There's variety of
white papers available, which explain the AACS concept. The same papers were used by
musilix64 in making his first breakthrough on circumventing the AACS protection.
But there is more to be found on their website... There's even a section which explains the
Consumer Benefits of AACS.
- Support a superior viewing experience delivered by next generation media formats
AACS is added to the content. The content itself will probably 'work' better without AACS.
- Enable greater flexibility to manage distribute, and play entertainment content on a wider range of devices
This is a 'feature' for the publishing companies. Without the restrictive AACS protection, the content can be played on virtually every device. With AACS protection 'they' control on which device you can play the content.
- Enable groundbreaking home entertainment choices and the ability to use content on PCs and a range of CE devices
AACS is added to the content. The content itself will probably 'work' better without AACS.
- Work across a variety of formats and platforms
Five letters: L I N U X. AACS protected movies CANNOT be played on Linux. Only movies without the protection can be player on certain Linux players.
