On Thu, Jun 16, 2016 at 10:34:01PM +1000, matthew wrote:
I'm trying to download an iso for installation.
The image I want is here:
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/
8.5.0-live+nonfree/amd64/iso-hybrid/
In particular I'm wanting debian-live-8.5.0-amd64-c
Dan Ritter:
> On Fri, Jun 17, 2016 at 09:50:15PM +0200, Jochen Spieker wrote:
>>
>> Admittedly, one of the main issues with HTTPS is the number of
>> handshakes your hardware can do per second. That probably isn't a
>> problem for the CD image download server that we are discussing here.
>> But fo
Le tridi 3 messidor, an CCXXIV, Dan Purgert a écrit :
> Apparently, since I've never seen that one can split a cipher block in
> that manner. Have a link to the source?
No, I do not have a link. Or maybe yes, I have:
https://www.ietf.org/rfc/rfc793.txt
Relevant quote: "The TCP is able to trans
Nicolas George wrote:
>
> --9jxsPFA5p3P2qPhR
> Content-Type: text/plain; charset=iso-8859-1
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> Le tridi 3 messidor, an CCXXIV, Dan Purgert a =E9crit=A0:
>> Because the TCP "stream" is still encapsulated in IP packets / Eth
Le tridi 3 messidor, an CCXXIV, Dan Purgert a écrit :
> Because the TCP "stream" is still encapsulated in IP packets / Ethernet
> frames, and you cannot simply "break" an encrypted block at some
> arbitrary point in order to make it fit nicely in the packet / frame.
Actually, this is exactly how i
On Fri, Jun 17, 2016 at 09:50:15PM +0200, Jochen Spieker wrote:
>
> Admittedly, one of the main issues with HTTPS is the number of
> handshakes your hardware can do per second. That probably isn't a
> problem for the CD image download server that we are discussing here.
> But for (non-distributed)
Pascal Hambourg wrote:
> Le 18/06/2016 18:19, Dan Purgert a écrit :
>> Pascal Hambourg wrote:
>>> Le 17/06/2016 21:52, Jochen Spieker a écrit :
Pascal Hambourg:
>
> Hmm. I don't know how SSL works, but HTTPS runs on top of TCP so I doubt
> that it cares about IP packet size. The ta
Le 18/06/2016 18:19, Dan Purgert a écrit :
Pascal Hambourg wrote:
Le 17/06/2016 21:52, Jochen Spieker a écrit :
Pascal Hambourg:
Hmm. I don't know how SSL works, but HTTPS runs on top of TCP so I doubt
that it cares about IP packet size. The task of splitting the TCP payload
stream into IP pa
On 06/18/2016 12:19 PM, Dan Purgert wrote:
> Pascal Hambourg wrote:
>> Le 17/06/2016 21:52, Jochen Spieker a écrit :
>>> Pascal Hambourg:
Hmm. I don't know how SSL works, but HTTPS runs on top of TCP so I doubt
that it cares about IP packet size. The task of splitting the TCP payload
Pascal Hambourg wrote:
> Le 17/06/2016 21:52, Jochen Spieker a écrit :
>> Pascal Hambourg:
>>>
>>> Hmm. I don't know how SSL works, but HTTPS runs on top of TCP so I doubt
>>> that it cares about IP packet size. The task of splitting the TCP payload
>>> stream into IP packets is done by the TCP lay
Le 17/06/2016 21:52, Jochen Spieker a écrit :
Pascal Hambourg:
Hmm. I don't know how SSL works, but HTTPS runs on top of TCP so I doubt
that it cares about IP packet size. The task of splitting the TCP payload
stream into IP packets is done by the TCP layer.
Sure, but if your encryption schem
Pascal Hambourg:
> Le 16/06/2016 22:13, Dan Purgert a écrit :
>
>> as well as making the overall amount of data
>> transmitted somewhat larger. This is because encrypted blocks have
>> specific size requirements (...)
>>
>> Remeber that a single packet can only carry 1460 bytes, before
>> accoun
Jörg-Volker Peetz:
> Jörg-Volker Peetz wrote on 06/16/16 15:12:
>> Did you take a look here: https://www.debian.org/CD/verify , "Verifying
>> authenticity of Debian CDs"?
>>
>> The https protocol would add quite some overhead to the download of the
>> iso-files which are already big by them self.
Le 16/06/2016 22:13, Dan Purgert a écrit :
Pascal Hambourg wrote:
Le 16/06/2016 18:18, Dan Purgert a écrit :
1)
So, the fact that HTTPS doesn't ~actually~ provide you with any security
when a "malicious party" has root accesss to the webserver,
AND that it
adds overhead to the transmission
On Friday 17 June 2016 04:15:51 Jörg-Volker Peetz wrote:
> Jörg-Volker Peetz wrote on 06/16/16 15:12:
> > Did you take a look here: https://www.debian.org/CD/verify ,
> > "Verifying authenticity of Debian CDs"?
> >
> > The https protocol would add quite some overhead to the download of
> > the iso
Jörg-Volker Peetz wrote:
> Jörg-Volker Peetz wrote on 06/16/16 15:12:
>> Did you take a look here: https://www.debian.org/CD/verify , "Verifying
>> authenticity of Debian CDs"?
>>
>> The https protocol would add quite some overhead to the download of the
>> iso-files which are already big by them
Jörg-Volker Peetz wrote on 06/16/16 15:12:
> Did you take a look here: https://www.debian.org/CD/verify , "Verifying
> authenticity of Debian CDs"?
>
> The https protocol would add quite some overhead to the download of the
> iso-files which are already big by them self.
>
This statement has to b
Pascal Hambourg wrote:
> Le 16/06/2016 18:18, Dan Purgert a écrit :
> 1)
>> So, the fact that HTTPS doesn't ~actually~ provide you with any security
>> when a "malicious party" has root accesss to the webserver,
>
>
>> AND that it
>> adds overhead to the transmission
>
> Does it really add network
Le 16/06/2016 18:18, Dan Purgert a écrit :
1)
So, the fact that HTTPS doesn't ~actually~ provide you with any security
when a "malicious party" has root accesss to the webserver,
AND that it
adds overhead to the transmission
Does it really add network overhead of just CPU overhead on the se
matthew wrote:
> [snip]
>
> There are MD5 and SHA sums in that same directory. However I can only
> access those checksums through unencrypted connections. Therefore they
> cannot be used to check against 3rd party tampering. (Since someone
> who has the ability to tamper with the .iso can also tam
On Thursday 16 June 2016 14:41:22 Matthew Davis wrote:
> (Sorry about the lack of pleasantries in my previous email. I haven't used
> these sorts of mailing lists before, so I just assumed it was all about
> going straight to business like on Stack Exchange.)
Both your emails seemed fine to me. :-
> Did you take a look here: https://www.debian.org/CD/verify , "Verifying
authenticity of Debian CDs"?
Yes I did. It's incredibly confusing. It's written with assumed knowledge that
a lot of users don't have. There are lots of hex strings with mysterious 3
letter abbreviations and no commands in
Did you take a look here: https://www.debian.org/CD/verify , "Verifying
authenticity of Debian CDs"?
The https protocol would add quite some overhead to the download of the
iso-files which are already big by them self.
Regards,
jvp.
Hi,
> There are MD5 and SHA sums in that same directory. However I can only access
> those checksums through unencrypted connections. Therefore they cannot be
> used to check against 3rd party tampering.
The chain of trust begins by the public keys as decribed at
https://www.debian.org/CD/verif
24 matches
Mail list logo
