superfish.pem
contains:
- the Superfish certificate as found by both Chris Palmer and Matt Burke;
- the encrypted private key as found by Karl Koscher.
$ openssl x509 -in superfish.pem -text
Certificate:
Data:
Version: 3 (0x2)
Well, I suppose its `safe' to release this, it seems everyone and their dog has | |
it and apparantly (and to my surprise) it still works. | |
The `smurf' attack is quite simple. It has a list of broadcast addresses which | |
it stores into an array, and sends a spoofed icmp echo request to each of those | |
addresses in series and starts again. The result is a devistating attack upon | |
the spoofed ip with, depending on the amount of broadcast addresses used, | |
many, many computers responding to the echo request. | |
Before I continue may I first say that this code was a mistake. When it was |
# You don't need Fog in Ruby or some other library to upload to S3 -- shell works perfectly fine | |
# This is how I upload my new Sol Trader builds (http://soltrader.net) | |
# Based on a modified script from here: http://tmont.com/blargh/2014/1/uploading-to-s3-in-bash | |
S3KEY="my aws key" | |
S3SECRET="my aws secret" # pass these in | |
function putS3 | |
{ | |
path=$1 |
# include <sys/types.h> | |
# include <sys/socket.h> | |
# include <ifaddrs.h> | |
# include <arpa/inet.h> | |
# include <netinet/in.h> | |
// Bad dirty quick functions written by hot fingers: | |
char* ipToStr(sockaddr* addr) { | |
static char ip[32]; |
# force HTTPS and www. | |
RewriteEngine On | |
RewriteCond %{HTTP_HOST} (?!^www\.)^(.+)$ [OR] | |
RewriteCond %{HTTPS} off | |
RewriteRule ^ https://www.%1%{REQUEST_URI} [R=301,L] | |
# alternative way | |
RewriteCond %{HTTP_HOST} !^$ | |
RewriteCond %{HTTP_HOST} !^www\. [NC] |
superfish.pem
contains:
$ openssl x509 -in superfish.pem -text
Certificate:
Data:
Version: 3 (0x2)
#!/usr/bin/perl | |
# http://www.mail-archive.com/[email protected]/msg04048.html | |
# this script would be run when smokeping detects some loss. The | |
# smokeping trigger could look like: | |
# | |
# +highLossTwice | |
# type = loss | |
# pattern = >70%,>70% |
#ifndef UNICODE | |
#define UNICODE | |
#endif | |
#include <Windows.h> | |
#include <string.h> | |
#include <stdio.h> | |
#include <Psapi.h> | |
#!/usr/bin/env ruby | |
require 'rubygems' | |
require 'json' | |
require 'pp' | |
require 'open-uri' | |
require 'cgi' | |
require 'httparty' | |
affiliate_id = 'olenaw-20' |
A reader asked me over email recently:
Have you posted anything or had any thoughts on Ghash.IO situation?
Nothing on this. I think it's just early volatility in bitcoin space. Some company (CEX) got serious about making a private mining farm and made a whopping share. Others will follow soon.
The dirty little secret of the blockchain is that it's not secure until increasing the hashrate by even 1% is an enormous economic feat. Currently it's not impossibly expensive to build your own farm with significant share - therefore the network is not very theoretically secure. Even if every existing pool had no more than 10%, you can't be sure that some guy does not unleash enormous hashing power at once and reverts some transactions.
When more companies start building private farms (and they will, it's the only cost-efficient way to mine; individual miners will soon disappear), you'll see more even distribution of the hashrate, but most importantly, the growth of hashrate will get slower. Because the slo
# Reverse proxy for Shinken 2.0.x on Debian Wheezy | |
# Place this file under /etc/nginx/sites-available | |
# Update your server_name | |
# Don't forget to enable the config and reload nginx | |
# Enjoy ^^ | |
server { | |
# IPv4 support | |
listen 80; | |
# IPv6 support | |
listen [::]:80; |