Downloading files from SSH over an unstable connection

October 9th, 2011

As mentioned earlier I am doing a lot of traveling at the moment, which means that I am mostly on a mobile connection.

I needed to download a 100Mb file from my Linux server, and with scp the download would fail.

Instead I am now using this rsync command that would resume if the connection drops:
rsync –partial –progress –rsh=ssh root@rauw.dk:filename.exe filename.exe

Also, if you are using SSH on a slow connection, typing things make lag, you can use this command:

rlwrap -a ssh user@address

X11forwarding on Mac OS X

October 5th, 2011

I am currently sitting in a position where the only way to get internet is through a mobile connection. This means that large downloads often are not possible because of the connection drops.

I needed to download a 500 mb file from RapidShare, that does not allow resuming of download after a connection drop (at least not for non-paying users). My idea was to let my server download the file and to let me download it afterwards with resuming.

The only problem was: The captcha since my server isn’t running a graphical user interface.

I found a program called Plowshare, that can download from a lot of download-websites, and send the Captcha image to my computer through the X11 connection.

Hvordan ikke-tydelig sikkerhed kostede GAD et bogsalg

September 27th, 2010

Jeg skulle købe en bog, og jeg startede så med at søge efter bogens titel på Google. Jeg finder bogen på siden bogpriser.dk, som der kan ses her:

boghandel

Der er en række billige boghandlere hvis navne jeg ikke kender, og så er der GAD’s onlineboghandel. De er et firma jeg har hørt om før, og mener derfor de virker mere troværdige end de andre forhandlere og vælger at bestille fra dem, selvom de er lidt dyrere.

Da jeg kommer til at skulle indtaste mine dankort-oplysninger ligger jeg mærke til at siden ikke er krypteret, og der står ikke ‘https’ i adresse feltet, derfor vælger jeg at afbryde min handel, og købe ved en af de billigere forhandlere som har en krypteret forbindelse. Og bogen er blevet sendt afsted i dag.

Jeg overvejer at klage til GAD (Og evt. melde dem hvis de modtager kreditkort data ukrypteret), så jeg undersøger deres bestillingsside endnu en gang. Adressen som kreditkort-siden befinder sig på ser således ud:

Screen shot 2010-09-27 at 3.19.15 PM

Umiddelbart skulle man gå ud fra at forbindelsen ikke er krypteret. Boksen hvor man skal indtaste oplysninger i ser sådan her ud:

Screen shot 2010-09-27 at 3.26.01 PMOg ved nærmere inspektion viser det sig at denne boks peger på en krypteret forbindelse til en server hos firmaet Quickpay. Så forbindelsen er krypteret, men der er INTET gjort for at gøre kunden opmærksom på det.

Det har kostet et salg fra mig, men hvor mange andre har opdaget det og fundet et andet sted at handle?

SSH tricks

August 27th, 2010

Bruger man SSH til dagligt på mange forskellige maskiner, så er der her en række tips som gør alt så meget nemmere.

Se dem her

KKIK har dårlig sikkerhed

July 26th, 2010

UPDATE: Problemet er løst, se bunden.

Jeg sad og kiggede på kollegieværelser på Kollegiernes Kontor i Københavns hjemmeside (KKIK), hvor jeg skal til at oprette mig som bruger. Man skal udfylde en masse personlig information, både navn, bopæl og CPR-nummer. Jeg ligger dog mærke til at  siden hvor man udfylder CPR-nummer ikke er krypteret, og begynder at undersøge det nærmere.

Jeg undersøgte siden, kastede tilmeldingssiden igennem Wireshark på en virtuel maskine, og bekræftede min frygt: DE SENDER AL DATA I KLAR TEKST (OGSÅ PERSONFØLSOMME FELTER!)

Dette er i modstrid med lovgivningen, og man må ikke sende eller opbevare CPR-numre ukrypteret. Det gør det muligt for ondsindede personer at lave et såkaldt Man-in-the-middle (MITM) angreb, og få fat i personfølsom data meget nemt.

Her er hvad jeg gjorde for at bekræfte at dataen bliver sendt ukrypteret over nettet:

1. Jeg gik ind på deres tilmeldingsside, og forsøgte at oprette en bruger med følgende falske oplysninger:

kkik3

2. Jeg installerede og åbnede Wireshark, trykkede på “Record” for at optage pakker, og trykkede send på KKIK’s hjemmeside. Og kiggede så pakkerne igennem for data. Jeg fandt meget hurtigt hvad jeg ledte efter:

datastream

Snak med datatilsynet

Jeg ringede så efterfølgende til Datatilsynet, og fik fat i en derinde. Jeg fortalte hende historien, og så spurgte hun om det var en offentlig enhed eller et privat firma (Betyder dette noget? Det er personfølsom data der er ukrypteret!).

Efterfølgende mente hun så at jeg ikke kunne se om det var krypteret eller ej, da nogen hjemmesider ikke viser at man benytter HTTPS. Jeg spurgte om hun kunne uddybe dette, det kunne hun ikke. Hun sagde så at jeg skulle tage kontakt til KKIK, og gøre dem opmærksom på problemet.

Snak med KKIK

Jeg snakkede kort med KKIK, og de mener at man bare kan lade være med at udfylde feltet, det er nemlig ikke krævet at du udfylder feltet. Problemet er at når du først har trykket på feltet, ændrer de input-feltets style, og man kan ikke længere se om feltet er krævet eller ej.

Men det er meget klart: Vil man modtage CPR-numre (krævet eller ej) så skal det ske over HTTPS.

Betyder det at de omgår loven ved ikke at kræve feltet udfyldt? Og er det så iorden at sende CPR-numre i klar tekst over internettet?

Eftersom de ikke ville anerkende at de gjorde noget forkert, og jeg godt kunne se at jeg kom til at være kontakt person mellem KKIK og Datatilsynet tog jeg kontakt til journalisterne på Version2.

UPDATE: Dagen efter firmaet bag blev opmærksom på problemet var det fikset, og hele siden var krypteret. Det virker ikke som om KKIK anede hvad de talte om, og bare prøvede at spise mig af med en undskyldning.