If you have a broadband modem in your mobile computer, like a Gobi 2000 modem in a Lenovo Thinkpad X201 or T510, you might be required to send USSD commands to manage the SIM card.

If you use a SIM card with a prepaid (pay as you go) plan, you might have to send USSD codes like *100# to check your balance, or send codes to load the money from a voucher, or to change the data plan you're using.

In the past, I've been able to use the prepaid-manager-applet utility to send USSD codes and view the response.

Recently I tried to do so again, but failed. The prepaid-manager-applet utility failed with an error:

"GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ModemManager was not provided by any .service files"
(see also the bug report at https://bugzilla.redhat.com/show_bug.cgi?id=984969 )

I learned that current NetworkManager versions no longer support the old D-Bus interface named org.freedesktop.ModemManager, but have introduced an incompatible interface named org.freedesktop.ModemManager1.

Unfortunately, prepaid-manager-applet doesn't support the new interface yet, so I searched for a replacement. I found the modem-manager-gui software, and tried to use it.

Unfortunately, it didn't work either, but for a different reason. The NetworkManager and ModemManager software attempted to access the Gobi 2000 modem using the newer QMI protocol. However, the implementation of the QMI protocol in NetworkManager and in libqmi doesn't yet support handling USSD commands.
(see also https://bugs.freedesktop.org/show_bug.cgi?id=84982 )

The QMI protocol is used by some modems as a replacement for the classic AT modem commands. Luckily the Gobi 2000 modem still supports those classic commands, too.

Thanks to advice from Dan Williams (dcbw), I learned that it is possible to force ModemManager and NetworkManager to use the classic interface, by disabling the use of the qmi_wwan kernel module. This can be achieved by creating a new file named e.g. /etc/modprobe.d/blacklist-qmi.conf and edit it to contain the text "blacklist qmi_wwan" (without quotes).

After you reboot, and perform the usual steps to activate the modem (which is a different story), I tried again to use the modem-manager-gui utility, and it was successfully able to send USSD commands!

Dan advised that some functionality might be missing when blacklisting the modern qmi_wwan module, but at least in my case, it's working fine (I can connect to the Internet using the broadband modem).

Finally, I'd like to mention another workaround for sending USSD commands, which doesn't require to blacklist the qmi_wwan module.

It's possible to use the minicom terminal software to interactively send USSD commands to the modem.

The Gobi 2000 modem creates three ttyUSB devices, I had to experiment which one can be used. In my case it was /dev/ttyUSB1.

I used the following commands:

Start minicom:
minicom --device /dev/ttyUSB1

Turn on echos:
CTRL+A e

Enter a command to check that interaction with the modem is working, some device information should be printed:
ATI

Now send the USSD command that you wish, in the following replace the text USSD with the command you would like to send (such as *100#), and KEEP the quotes:
AT+CUSD=1,"USSD",15

After a few seconds, it printed the balance on my SIM card. You should be able to use the same mechanism to send charge codes, such as *101*CASHCODE#

Do you run a SSL/TLS server?
Do you still use a server certificate that uses a SHA-1 based signature, because it was the default when you requested it, and you didn't notice?
Are your users worried that your server uses a weak certificate?
Do you want to migrate to a SHA-256 server certificate?

If yes, you should request a replacement certificate from your Certificate Authority.
First, you should check if your CA offers SHA-256 certificates at all.
Your CA probably requires you to send in a CSR (certificate signing request). And you really should create the CSR yourself. This ensures the private key for your new certificate is stored on your systems, only.
When you create the CSR, you should ensure it contains a SHA-256 signature.
If you use the "openssl req" command for creating the CSR, you must add the "-sha256" parameter.
If you use the NSS "certutil -R" command for creating the CSR, you must add the "-Z SHA256" parameter.
(Both parameters seem to be undocumented at the time of writing this blog post.)

Your CA might require you to pay for the replacement certificate, while your old certificate is still valid.

I'd like to talk about the StartSSL.com CA in particular, because many sites use their free certificates (and so do I).

However, when using a Class 1 free certificate from StartSSL, in order to get a replacement certificate (for the same hostname), it's necessary to revoke the existing certificate. And revoving a certificate isn't free with StartSSL. This means, you'd have to pay for revocation of each of the certificates that you want to replace ($25 each).

So, if your SHA-1 based certificate is still valid at the time you're reading this, but you don't want to pay anything, you need to wait until it expires. Only after it expires can you request a new certificate for the same hostname. And make very sure you request a SHA-256 certificate, not another SHA-1 (don't risk being blocked for another year, by being stuck with another SHA-1 cert).

If you're willing to pay, and if you want to migrate multiple certificates, it's cheaper to get an identity verification, which is $60.

Once you are verified, you can issue certificates that contain multiple hostnames. And this makes it possible to create replacement certificates, without having to revoke your old certificates.

For example, let's assume your existing certificate was requested for CN=example.com, and it is valid for hostnames example.com and www.example.com.
If you request a replacement certificate with the same hostnames, without having revoked the old certificate, StartSSL will give you an error message, suggesting you to revoke the old one.

One solution is to include an additional subdomain when asking for the certificate. It doesn't matter if you're actually using that subdomain (hosting content on the subdomain), you could use one that you don't plan to use at all. For example, let's use a subdomain "sha2".
If you request a new certificate for CN=sha2.example.com, and you request inclusion of the hostnames sha2.example.com, example.com and www.example.com, then the subject name of your new certificate will be different from the old certificate's subject name, and StartSSL will allow you to get a certificate in parallel to the old one.

Once you have obtained an updated certificate and are ready to install it on your server, don't forget to update your server configuration to use an appropriate intermediate CA certificate, too. For example with StartSSL, you can find the SHA-256 based class 2 intermediate certificates for servers here.

TL;DR : If you are a system administrator for infrastructure using X.509/PKI certificates, please check that your infrastructure doesn't depend on the following CA certificates to be trusted. Although their validity dates indicate they are still valid, they will be removed in upcoming software updates. If you depend on them, you are likely to experience failures. Talk to your CA and make sure you refresh affected certificates on your systems.


In order to avoid weak signing keys in the PKI trust infrastructure used by the global web, several CA certificates with weak 1024-bit keys have been removed by the maintainers of the Mozilla CA certificate list.

The current cleanup of 1024-bit keys affects the CA certificates with the following properties:

CN=Entrust.net Secure Server Certification Authority,OU=(c) 1999 Entrust.net Limited,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),O=Entrust.net,C=US
SHA1 Fingerprint: 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39

E=info@valicert.com,CN=http://www.valicert.com/,OU=ValiCert Class 1 Policy Validation Authority,O="ValiCert, Inc.",L=ValiCert Validation Network
SHA1 Fingerprint: E5:DF:74:3C:B6:01:C4:9B:98:43:DC:AB:8C:E8:6A:81:10:9F:E4:8E

E=info@valicert.com,CN=http://www.valicert.com/,OU=ValiCert Class 2 Policy Validation Authority,O="ValiCert, Inc.",L=ValiCert Validation Network
SHA1 Fingerprint: 31:7A:2A:D0:7F:2B:33:5E:F5:A1:C3:4E:4B:57:E8:B7:D8:F1:FC:A6

E=info@valicert.com,CN=http://www.valicert.com/,OU=ValiCert Class 3 Policy Validation Authority,O="ValiCert, Inc.",L=ValiCert Validation Network
SHA1 Fingerprint: 69:BD:8C:F4:9C:D3:00:FB:59:2E:17:93:CA:55:6A:F3:EC:AA:35:FB

These removals happened in version 2.1 (2014) of the CA certificates list, which has been published as part of the NSS release 3.16.3 and which has been amended in 3.16.4.

The upcoming Firefox 32 release, which is expected around September 2nd, 2014, will use this cleaned up list.

Since many other open source software packages or operating systems have chosen to use the Mozilla CA list as the base for global Internet trust, the list is widely distributed, and you should expect software updates with these removals. For example, this affects the ca-certificates package in the Fedora Linux distribution.

To analyze if you depend on the CA certificates listed above, for example, you could check which trust chain is presented when connecting to your server. For example, you could try to use a command like this to retrieve the certificates sent by the server:

$ openssl s_client -showcerts -connect kuix.de:443

Update 2
The output of the above command will display the issuer and subject names of all certificates sent by the server. If one of the issuer names matches with a name in the removal list, then you could be affected. The full check requires additional effort. It depends on your software, whether it will build a trust-chain to one of the removed CA certificates - which will fail after the removal. The names alone cannot tell, because replacement intermediate CA certificates might exist, with identical names, but different (good) properties.

When in doubt, check with your CA. Alternatively, you could configure a test system to no longer trust the removed CA certificates, and see if a connection (or a certificate validation) fails.

(In an earlier version of this blog post, I had suggested a check that doesn't work. It doesn't work to compare fingerprints of certificates sent by a server, with fingerprints shown in the list, because servers don't send the root CA certificate, but only intermediate CA certificates. I apologize for my earlier mistake in thinking.)
end of Update 2

If you find a certificate shown in the above list, then you should work with your CA to get a replacement certificate quickly, and update the configuration of your infrastructure. In some scenarios it may be sufficient to replace the intermediate CA certificate configured on a server, which allows clients to find an alternative chain of trust to a different server. Please ask your CA for details, if such an intermediate CA certificate is available, or if you must update to a refreshed server certificate (including the respective, different intermediate CA certificates).

As an example, several web sites have been found to still use an intermediate CA certificate with the following subject:

CN=USERTrust Legacy Secure Server CA,O=The USERTRUST Network,L=Salt Lake City,ST=UT,C=US

which had been issued by the removed Entrust.net CA certificate. (Note that Entrust.net hasn't been removed completely, only an older certificate with a weak 1024-bit key.)

In order to limit the impact of the removal, this CA has issued a replacement intermediate CA certificate, which has been signed by another CA certificate with a stronger key. This intermediate certificate has been included in the Mozilla CA policy list, with neutral trust settings, intended as a helper certificate, that can allow software to find the path to a different trusted root.

However, only a limited number of software libraries performing X.509 certificate validation are able to make use of this helper certificate in their default configuration. For example, the NSS library will notice the replacement intermediate CA certificate being present in the certificate store, and because the replacement certificate has been configured by the CA to contain newer validity timestamps, it will be preferred by NSS, and the chain to another CA certificate with a stronger 2048-bit key will be found.

It seems that applications based on OpenSSL and GnuTLS typically don't use the replacement intermediate certificate, even if it's available in a certificate store during the validation. Therefore it's important to configure servers to send the correct intermediate CA certificate.

Note this is a first batch of removals of 1024-bit CA certificates. The Mozilla CA certificate list still contains entries with weak 1024-bit, and there are plans to remove them in future updates. If you'd like to learn more or discuss these changes, please refer to Mozilla's dev-security-policy discussions list.

Please help to distribute this information. Thank you.


UPDATE

While we have your attention, here is a list of additional weak 1024-bit CA certificates that are planned to be removed at a later time. If you depend on them, make sure you start to work with your CA to get them refreshed by your CA, too.

GTE CyberTrust Global Root, GTE CyberTrust Solutions, Inc., GTE Corporation, US
SHA1: 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74

Thawte Consulting cc, Certification Services Division, Thawte Server CA
SHA1 Fingerprint: 23:E5:94:94:51:95:F2:41:48:03:B4:D5:64:D2:A3:A3:F5:D8:8B:8C

Thawte Consulting cc, Certification Services Division, Thawte Premium Server CA
SHA1 Fingerprint: 62:7F:8D:78:27:65:63:99:D2:7D:7F:90:44:C9:FE:B3:F3:3E:FA:9A

VeriSign, Inc., VeriSign Trust Network, VeriSign Class 3 Public PCA – G2
SHA1 Fingerprint: 85:37:1C:A6:E5:50:14:3D:CE:28:03:47:1B:DE:3A:09:E8:F8:77:0F

Equifax Secure Inc., Equifax Secure eBusiness CA-1
SHA1 Fingerprint: DA:40:18:8B:91:89:A3:ED:EE:AE:DA:97:FE:2F:9D:F5:B7:D1:8A:41

Equifax Secure Certificate Authority, Equifax Secure CA
SHA1 Fingerprint: D2:32:09:AD:23:D3:14:23:21:74:E4:0D:7F:9D:62:13:97:86:63:3A

Equifax Secure Inc., Equifax Secure Global eBusiness CA-1
SHA1 Fingerprint: 7E:78:4A:10:1C:82:65:CC:2D:E1:F1:6D:47:B4:40:CA:D9:0A:19:45

I've started yet another project to solve "the right key" problem.

DetecTor is an open source project to implement client side SSL/TLS MITM detection, compromised CA detection and server impersonation detection, by making use of the Tor network.

In short, make use of the existing Tor network, perform multiple
connections to the destination server through multiple routes, check for consistency in the use of certificates, and either fail or proceed automatically, without user interaction.

The detailed description of the idea, including suggestions for the handling of edge cases, can be found at http://detector.io/

Looking forward to your feedback.

If your flight takes to you Frankfurt (FRA) airport and you've got a few hours to spend, you could do the following to make use of it do to some sightseeing:

Go to the regional train station below Terminal 1, take regional train S8 (S-Bahn), exit at Taunusanlage station.
Look at nearby Alte Oper from outside,
walk through FressGass which starts right next to it,
walk through Goethestraße,
then walk to nearby MainTower for a nice view from above,
the only skyscraper allowing visitors on top of the building
(airport-like security screening when entering).
http://www.maintower.de/hlb/generator/S ... er.en.html

Afterwards walk to Paulskirche, then Dom/Römer with its historical buildings and tourist souvenir shops, and you have the essentials covered.
You could continue to the nearby river Main, cross the Eiserner Steg pedestrian bridge, and head to the right for lots of museums and Schweizer Straße with traditional applewine restaurant Wagner http://www.apfelwein-wagner.com/

Have fun, Kai