On Wed, Apr 11, 2018 at 09:52:41PM +0200, Peter J. Philipp wrote:
| So I re-downloaded this file on another machine. It turned out to have your
| checksum (sha256 -b) and upon downloading another SHA256.sig it signify'ed
| correctly. But this leads me to ask questions:
|
| 1. doesn't the https mode ftp use some sort of authentication/integrity
| checking while it's downloading? It's encrypted and anyone with a bit of
| knowledge knows that if encryption is changed in-flight it will flip bits,
| but with a MAC/HMAC/GMAC it should detect any anomalies. Does ftp not check
| for this?
ftp doesn't do this itself, but the error detection in tcp and ssl
(ok, so that's linked into the ftp binary) do.
The file is unlikely to have been changed in flight.
| 2. I use quite recently a new unencrypted wifi network but I have IPSEC
enabled
| which uses aes-256 and auth hmac-sha2-256:
|
| SAD:
| esp tunnel from fd43:5602:29bd:16:0:dead:beef:16 to
fd43:5602:29bd:16:0:dead:beef:1 spi 0x6ab04db8 auth hmac-sha2-256 enc aes-256
| esp tunnel from fd43:5602:29bd:16:0:dead:beef:1 to
fd43:5602:29bd:16:0:dead:beef:16 spi 0x780a14d0 auth hmac-sha2-256 enc aes-256
|
| It is entirely possible that my IPSEC was off minutely and the gif tunnel
inside it was not protected, but there was still the https...
This is probably also not relevant to the result you got.
| 3. The argument that this may have been modified by ftpmirror (or similar
software) is good but I stat'ed the file and it's larger than what was
downloaded by
| us on the second try. A cmp -l shows a lot of differences... here is the
stat:
| theta$ touch test
| theta$ date
| Wed Apr 11 21:45:16 CEST 2018
| theta$ stat test
| 1034 8616981 -rw-r--r-- 1 pjp pjp 0 0 "Apr 11 21:45:15 2018" "Apr 11 21:45:15
2018" "Apr 11 21:45:15 2018" 32768 0 0 test
| theta$ stat install63.iso
| 1034 8616961 -rw-r--r-- 1 pjp pjp 34424768 355905536 "Apr 11 20:59:23 2018"
"Apr 11 19:33:47 2018" "Apr 11 19:33:47 2018" 32768 695360 0 install63.iso
That's actually *smaller* than what I have here. The install63.iso I
got is 355909632 bytes in size. Your file is missing 4096 bytes.
| I did mount this iso with vnconfig is it possible that it was modified then?
| (and grew?).
No, vnd's don't grow in size during mount. Their atime may change,
but I don't think much else will (not in the case of ISOs, which are
read-only by nature).
| 4. Is it possible that there was an attack on the OpenBSD network
infrastructure?
Unlikely. Probably, the bytes you got match 1:1 with the file I got,
minus those last 4096 bytes. There's probably nothing all that
interesting in those last 4K of the ISO, so my guess would be that
everything would still be fine. You can verify that by checking the
contents of the mounted file system against the SHA256 file.
| 5. Or mine?
Also unlikely. Could the download have been interrupted at the last
moment?
Cheers,
Paul
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
