... and another Apache httpd story ... client authentication of proxied requests

Centos/RHEL 6.3, apache httpd 2.2.15
The goal is - let te httpd listens at port 80 plain unencrypted HTTP requests. The request will be forwared  to https://some.site/ where there is a HTTPS with client authentication.

Findings:

Client certificate key/cert file format (directive SSLProxyMachineCertificateFile):

• key + certificate need to be in single PEM file looking something like
  -----BEGIN RSA PRIVATE KEY-----
  MIIE...
  ...
  ...
  ...
  -----END RSA PRIVATE KEY-----
  -----BEGIN CERTIFICATE-----
  MII...
  
  ...
  .,
  ...
  -----END CERTIFICATE-----
• mind the RSA part (emphasized above)  of private key header - some openssl versions use the header with and some without the RSA letters
• without RSA
• my version of apache httpd wants it there

Re-negotioation at the server side is not supported. The server should be configured to protect every request with client auth. To avoid TLS renegotiation when entering protected resource, SSLClientVerify should be configured at VirtualHost level or server level.

After above changes were made server started and operated as expected.

References:
http://apache-http-server.18135.x6.nabble.com/Apache-fails-to-start-if-SSLProxyMachineCertificateFile-does-not-contain-RSA-td5009238.html

Apache httpd 2.4.6 hangs not servicing HTTPS

A lot of pain ... till solution found
# Apparently this fixes an issue with Apache 2.4.6 on Windows hanging
# when serving requests from Internet Explorer 10/11.
# see http://stijndewitt.wordpress.com/2014/01/10/apache-hangs-ie11/
AcceptFilter http none
AcceptFilter https none

... Google Authenticator or Doogee DG800 strange error

After purchasing new chinese Android phone I needed to install Google Authenticator. But had no luck. The application worked fine but ... generated codes did not work. I tried other phones and came to a strange conclusion. The other Doogee DG800 I had show she same codes. Bud all other Android phones shown different codes. For sure all the phones shared the same secret.  The strange thing was the codes were different in some digits only. Typical difference looked like this 605678 - 604356.

As the authenticator codes are derived using hash function (RFC 6238 - TOTP), in case of an error there should be completely different results.

Fortunately - authenticator is an open source software. I cloned the repository and built my own version for debugging.

And here is the source of difference. During the computation a piece of a hash value is taken, converted to integer and then divided by a power of 10 and the remainder is the code:

int code =  truncatedHas % (int)Math.pow(10, codeLength);

On the problematic phone the result of power computation was this:
 Math.pow(10, codeLength): 999999,99999999

After cast to integer the result was 999999.

This is the answer - wrong result from system runtime library because the Math.pow function computes doubles which can be not so precise.

It is rare but it happens.

I'm going to  send a patch which does not uses double computation.

UPDATE: Issue was discussed at Stack Overflow. The main cause is a bug in the phone platform library.

... firefox 30+ disabled NTLMv1 over insecure connection

NTLMv1 is known to be insecure but if you need it new setting was introduced:
network.negotiate-auth.allow-insecure-ntlm-v1 - defaults to false and NTLMv1 auth request is silently ignored when sent over HTTP. Set it to true to force NTLMv1authentication prompt.

Disclaimer: NTLMv1 over HTTP is considered insecure - you should know what are you doing

... nssm - non sucking service manager

Seems really usable - new to me.
Why I like it ... it is able to start any command as a service and has several options for service shutdown (Send Ctrl-C, send WM_CLOSE,kill process)

http://nssm.cc/usage

Chrome native messaging on windows

Problem:
When developing extension using native messaging you need to develop so called native messaging host - exe which is registered with chrome and  spawned by chrome when requested by the extension.
Chrome uses pipes to communicate with the host. The pipe is connected to stdin/stdout descriptors in the host process.
There is a drawback on windows - default stdin mode is TEXT. But in this mode once 0x1A is passed through, the C library closes the pipe and the host is terminated because 0x1A id end of file marker.

Solution:
Before reading attempt from the pipe set the mode to binary (defaults to text) using following code snippet:

_setmode( _fileno( stdin ), _O_BINARY )

Reference: http://msdn.microsoft.com/cs-cz/library/tw4k6df8.aspx

Convert SSH public key to a form for .authorized_hosts

Evary time i need this command it takes me minutes to retrieve the right form from my memory. Let's take a note :)

ssh-keygen -i -f pem -f ~/.ssh/id_rsa.pub

Error 'LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt - Solved

No Visual Studio 2012 installed just SP1 of Visual Studio 2010.

Found this (no solution, but direction): http://stackoverflow.com/questions/10888391/error-link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-inval

But it did not help.

Found this(almost solusion): http://social.msdn.microsoft.com/Forums/vstudio/en-US/d10adba0-e082-494a-bb16-2bfc039faa80/vs2012-rc-installation-breaks-vs2010-c-projects?forum=vssetup

It pointed me to the root cause - bad version od cvtres.exe which depends on missing msvcr100_clr0400.dll.

Solution: downloaded http://www.dll-files.com/dllindex/dll-files.shtml?msvcr100_clr0400

I downloaded the right version (32bit) of the file and stored it next to cvtres.exe and BINGO!!! compiling with no error.

Sahme on MS ... and shame on MS problem resolution culture. Searching the root cause is seldom seen. Uninstall/Reinstall is the only advice in most of dicussions.