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
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
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
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 /
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
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
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
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
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
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
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
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
>>
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
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
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
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
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
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
24 matches
Mail list logo
