Sending confidential information across the Internet is always risky as you never really know who or what may intentionally or accidentally look at a copy of your communication at some points.

Various tactics can be used to reduce the risk when sending confidential information. The current approach accepted by most people is the use of PGP or GPG. PGP and GPG are commercial and open source (respectively) implementations of asymmetric encryption system specifically designed to work with visible text communication.

Asymmetric cryptography works by using a key pair. When some thing is encrypted using one of the keys only the other key can be used to decrypt the encrypted text. This allows you to give away your public key to any one and every one and know that any thing some one encrypts with it cannot be retrieved any one other than your self. It is currently technically infeasible, and has stood up to 10 years of scrutiny so far, to determine one of the keys of a pair when having one of them.

The only real trouble after using this system is communicating the public key and knowing it has not been tampered with.

If you need to send Edmonds Commerce any confidential information securely feel free to encrypt it with our public key:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.11 (GNU/Linux)

mQINBFELsYgBEAC5+Rox1iibzg19OkMCcaeApJPxX4mdzlPoRugc5ObMkjltmSPC
vlTKqhCXk0Ms8p4H0lOkomNSkJQ8oJvCTZRjMQMn+9lGYvUw5mLbv6dZbemGCJ2H
7RuC7NWjsm/pa/tcKg9kDxQKH1iIo60KEMaUE/xmrXyJedQpSnIZ8EtWvqvi57sy
ov87xia9a8azTfoZSQ4wHbTkcmYMyM2+LBBymuKhDa7XdlJBK1w0jhm1AXbEwl64
bxVRgf5tGAf/TGKdyIGQfU5+uzgXLRH/xMKr0LN4DChhl5yF9e2ISN/BSwClZdmI
yHfIo/sPh7wOoPGNtHmoapZBrx+2pm894agMM3mwRJJHEMZ/gxxu3b+2gNxgViYu
+h2THP0CZCD/MtMb7WuDdWdA/KOX2us71PRa3u5QzYIKqDn3/P0ZsZ6aZfxfvpYA
2d2xePX3QSyi8quP5sffCOWVTDhtQLKuG/y2jZRx8YRzWBR0OGkyFpVJcALBRIGy
0pSDEIdzAAy6c/qznSp/rFqbRVpfnvUY6kQjVtFK3GiLyDGZ2Jy1y+Ie3NWhBDQC
6WLyMN54/dw9rT2mOd+Sr+Uy46hczNbnG4H8GPBuEc6CpThnCXa+nrBYM5G6Hjfk
TvmflBnNiG/Qx1QkKJSkIvcZlmRmEOFBmxL+5YBsfpylCsYiloNR54q+HwARAQAB
tEhFZG1vbmRzIENvbW1lcmNlIChFZG1vbmRzIENvbW1lcmNlIEdQRyBLZXkpIDxp
bmZvQGVkbW9uZHNjb21tZXJjZS5jby51az6JAjgEEwECACIFAlELsYgCGwMGCwkI
BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEC3xjF4doRBxDQ4P/04+KIZ9k7nbCipK
ff4AtLMolzPey+BHG3c83msQcVeZbwqkqAiTRzs4BIt+M5Hjc+hoqj+bk609SSOY
Q3MMTPqpgskRfjOyVwVSFLX1x/anf05yfsDQdoU94kYzeShJxYVHCLzOSAVs7DpE
kM52+eP6MP8oLCvrC9Ynuw+5O/95+H4+RW926wcKMx4m+q+B+Axi7WBRejkBgSw8
bOby+J+3xt6aJlee6pb2JuoIkSTKvidlk0W1NUiu3JL5iEttsbIR7SDQyCttUN9D
GqLMsLIHKgRwGgyBt6/yGYGOXC/lec1HTfoJ5fLKpFN4AUNjdkiLsaVk56od7VMs
hUunQW7q4UC4xK1U5gtIX5HHOgsWEXmvNlqAl5PCpCOVr4UzHeZgT3D88BRD/0k4
BqBjTLKkFW+pX7I3IofE6auXNqEdcGpsEsreqFM2bvhkK+zNo37Cu5GbN7NV/IrO
FYap2yI8sbVgth3sgWv6zxErRs0NHxbhYh8f0jUg9ewRwqHE5J4dk3nGVaLfI5xf
8vYnKmN7736S1FJn2Q8wkLlKBAxgZ+8sr98ISy3yM9X2w+flBdl7fuAMjkaSR4FH
8g8XryCjOK5rDQBVTYdbZasNdzJeJMv52k2Xo3rn+MpsNvco6fXYFKE+CyRBWV+z
lYoc1AuecVjh2SZ4AUCz+5BSimZQuQINBFELsYgBEACk1P1PYrlrC/yG1aVkqPHs
77MiRlVep/GL6Xgiwo0o8Ze73+5aCMzuEFSm5p83JfAEtq7ugZ5R1Ks/6FcM6CTi
96KmsYvHM7mP/qrOWel6sXXWPHHj9Pja4Lo1aIV+JNskmLfFe8ECsmxzt8hPTexZ
rCdNmoeDZC4Oqq4XNTWI74tlgCAd+Rw+0ZxuTe++Rce2vVanOz88dceT8CpMJpRU
sD0qAVR4g7HI0pelUcWuJrbC2M7TQeiggtzKkNHS/TVLLGKT8DbYPg7XBX4/ZUa9
j3NiJZ/UFD87rPBaNtd888qOMR+hSdqFv4YqJd79wWibBGhb2r6nfWegzqc3mxv3
AiMBTxz4fGI1VR3DWEJg6bGqQNJYHkfzuZloF++HYe3m2q7ucG47HEct56hRCXbd
wakdOuIMMJo7ubcVqctRFOsAAQUeK3a5SrG2HBWepa9gKJ2iYfmKp7Sw1fmWrDU7
UWXiKyFBCDEuRe9bcT/ZGUc+FtbRaawe1LD6lO6S0pmxBwlM8sKIxSUZYd0YebZ/
7Uv5k7d0KCBk3ct5zsdsXg77D/HjFbfSjLoDsyJQ6po5AofKguspelKPcCbPFzk/
6squ/lF8tSS3+wDi73D7WbPlGBpawzhqrnZ/DB3kkTg7sPWH40EC3V3B0x7dXLrM
VNmKLZmWvl2QMUFdxMzwvQARAQABiQIfBBgBAgAJBQJRC7GIAhsMAAoJEC3xjF4d
oRBxGPkP/j01QpQr7kTGit9fmIBMyThTKfEBKnkWRHklh46PPTI4lLetS20d4vtn
Y0ztABbKJbsP+ubii7Iir3Xkslaub8PMDH4QII4BkiIfihS3iyWyHMEBdJK1EfVA
wX5wmRt/uXmltSp6cJM13/7ML2KTs67eA1lYyDTNHtODdW2M/urzbtm0ATWCXXm6
ynWMXFPnOl+W8EQVLnWSX0wyGGjqAAmCvLm/Xbab2WCEfz1e3SX2pBDWDZOyX5z8
dgsRJQmgHBhGi1p0BG5YZIE/RcUHQE0gdJHlZerfaHRB350xP9xRlSXUwnTJUjEZ
T8Yaq+dtMdO7em+AFqXDpEQ8gHeiQ21/qE2g/xPvGOg9tuTYRuRVCDNiM1o+OXyO
vE6jIRiovm9Zvcx3yUWdLV/WZqtucYW6vBiZFlyGixd5MwH8qLbDKDnw2yJ5mhSr
FcI7Bc2V8cSrTMxvZ/X3u5Q2OPZVSDv1pMN89YKrLBiJA/moOOANr+vLkCyK/aJn
NbE2327dfs02XX+aMUWRHRN55ztPgmKu31ZDqc8tck7QnkCpKY71GaxID2SLOXmd
tLOgP7Peci/RC7EhiV9lh5ii5pVeDLCFhIoAkK+wJiDVdUkf3WLtTS7P+ahR7cvR
movN7o6BrTspRXqXVmoBi6YOFbNNoBP9N1BPDARz6Maeoc5iEfZZ
=ISyO
-----END PGP PUBLIC KEY BLOCK-----


There is a current vulnerability with skype accounts where anyone who knows your email address can get access to your account, and even your private chat logs.

According to Kaspersky Labs (a leading computer security firm), the leader of the Russian Opposition has had his private chat logs leaked via this method.

This is a serious vulnerability and Microsoft (the current owners of skype) are looking into the issue.  At present there’s no way to avoid the compromise, perhaps think about clearing your logs if you have anything private in there.

There’s a good article here that explains in more detail.

If you are using Google apps and have two factor authentication turned on then you are probably using the convenient “Remember this PC for 30 days” feature.

If you like your browser to forget every thing except a very select set of data (bookmarks, etc.) but keep the convenience of the 30 day authentication then you only need to keep the cookie called “SMSV” for the domain “www.google.com” with path “/a”.

There is a variety of ways you can keep this cookie. You could, for example, export it then import it when ever (and where ever) you need it.

Often you will see SSL warnings or errors related to insecure content being displayed on a secure page.

This could be as simple as one javascript file or image that is being included via http rather than https, though some times this can be a bit tricky to track down.

The easiest solution is to hit this site:

http://www.whynopadlock.com/

This will give you a clear report of the problems and should help you quickly find and fix them.

Alternatively if you use Chrome you may see the details in the Javascript console.

Once you know what elements are being called by http as opposed to https, you simply need to make them use https or remove them altogether.

If you are pulling your hair out trying to figure out why you are seeing a 501 error in your Google Checkout integration console I may well have the answer and solution for you.

This is the error message you will see in the integration console.

 	We encountered an error trying to access your server at https://domain.co.uk/googlecheckout/api/ -- the error we got is Sending failed with HTTP response code: 501. Response body was: <HTML> <HEAD> <TITLE>501 Not Implemented</TITLE> </HEAD> <BODY> <H1>Not Implemented</H1> The page you are looking for cannot be displayed because a header value in the request does not match certain configuration settings on the Web server.<P> <HR> <ADDRESS> Web Server at domain.co.uk </ADDRESS> </BODY> </HTML> <!-- - Unfortunately, Microsoft has added a clever new - "feature" to Internet Explorer. If the text of - an error's message is "too small", specifically - less than 512 bytes, Internet Explorer returns - its own error message. You can turn that off, - but it's pretty tricky to find switch called - "smart error messages". That means, of course, - that short error messages are censored by default. - IIS always returns error messages that are long - enough to make Internet Explorer happy. The - workaround is pretty simple: pad the error - message with a big comment like this to push it - over the five hundred and twelve bytes minimum. - Of course, that's exactly what you're reading - right now. --> 

The first thing to do is log into your server via SSH and examine the error logs.

find the error logs, open the file up in vi using this command:

vi error_log

Then go to the bottom of the file using the [shift] + [g] shortcut. Then to search backwards in the log use the following command:

?ModSecurity

If you find something with this error message then you have mod security installed. If you search around you may well find an error message like this:

[Thu Mar 26 10:22:11 2009] [error] [client 94.229.166.12] ModSecurity: Access denied with code 501 (phase 2). Match of “rx (?:^(?:application\\/x-www-form-urlencoded(?:;(?:\\s?charset\\s?=\\s?[\\w\\d\\-]{1,18})?)??$|multipart/form-data;)|text/xml)” against “REQUEST_HEADERS:Content-Type” required. [file "/etc/httpd/modsecurity.d/modsecurity_crs_30_http_policy.conf"] [line "71"] [id "960010"] [msg "Request content type is not allowed by policy"] [severity "WARNING"] [tag "POLICY/ENCODING_NOT_ALLOWED"] [hostname "247electrical.co.uk"] [uri "/googlecheckout/api"] [unique_id "-UMIen8AAAEAAFsDLH4AAAAB"]

This error message tells us which particular rule is causing it to fail. What we need to do now is either edit this rule or disable it altogether. I will first try to edit it so that the request can get through, but the rule is still active. The rule we need to edit is in this rules file:

modsecurity_crs_30_http_policy.conf

and is on line 71.

I’m no mod security expert. Having had a quick look through the documentation I am not sure how to edit this rule to allow Google Checkout callbacks through. So for the time being I am going to disable this particular rule altogether by adding a # in front of lines 70,71 and 72.

If any mod security experts out there read this blog and know a better solution please do post it in the comments.

More…

If you have a script, admin area or whatever that you would like to make a bit more secure, you can use the following chunk of code to do this. If you don’t have SSL (HTTPS) set up then you would need to get this sorted first.

This isn’t bullet proof protection, but it helps.

//IP addresses that you would like to be able to access the system
$allowed_ips[] = '99.99.99.01';
$allowed_ips[] = '99.99.99.02';
$allowed_ips[] = '99.99.99.03';
if(!in_array($_SERVER['REMOTE_ADDR'], $allowed_ips)){
	header('HTTP/1.1 500 Internal Server Error');
	exit();
}

//Force SSL Usage
if($_SERVER['SERVER_PORT'] != 443){ //assuming your server is running SSL on port 443
	$url = "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
   	header('Location: '.$url);
}

If your web site’s secure HTTPS area includes any content such as images, javascript or whatever via standard HTTP, your visitors may well get a security warning popping up saying that the page contains secure and insecure content.

For some of your sites visitors, this rather vague and worrying statement might make them decide to abandon your checkout procedure and cost you a sale.

Often this is very easy to fix.

Simply go to the page that is triggering the error message and “View Source”

Then in the source code, search for

src="http://

or

src=http://

Now that you have found the offending items, you either need to remove them from your secure pages, or ensure that they are using the https:// method when the pages are being viewed by HTTPS.

that’s it – dead easy

To get the highest possible level of server security and to protect yourself from things like XSS attacks, Edmonds Commerce highly recommend you get mod_security set up on your server.

If you ask your hosts they should be able to do this for you.

You can read all about mod_security here. If you would like any help getting mod_security set up on your server then simply get in touch.

One thing we always recommend doing to the standard mod_security configuration is to increase the maximum body size. This restriction by default limits the size of any web page to 500k.

For front end pages, there should never be a time when you need to display a page bigger than this size, however for some administration side systems, it is necessary to create very big pages. This mod_security limit will prevent these pages from being viewable.

To remedy this, you need to edit the file located in the modsecurity.d sub folder of your httpd folder (usually /etc/httpd/modsecurity.d/)

In this folder there is a collection of files which handle all of the various security rules that detect potential security threats. There is also a file called modsecurity_crs_10_config.conf.

Edit this file using vi and change the value for the SecResponseBodyLimit setting. We usually recommend upping this to 2mb from the standard .5mb. This means that the server is protected from doing really big things (for example a mysql dump) but is able to display really big admin side HTML pages.

To set it to 2mb you need to change the value of SecResponseBodyLimit to 2097152