TLS certificate sizes in Geminispace

[solderpunk]

On Fri, Jun 26, 2020 at 06:18:11PM -0400, Sean Conner wrote:
> It was thus said that the Great solderpunk once stated:
> > There are several contributing factors to TLS overhead.  
> 
>   I think some of the overhead concern is overblown.

Oh, I completely agree.  It seems to bother a lot of people so I've been
pointing out comparatively quick and easy things we could do without
changing the spec at all to address it, because I'd much rather do that
than increase complexity or reduce security.  But my personal experience
using AV-98 is that browsing Geminispace feels plenty snappy enough as is.
Especially relative to how long the content takes to consume.

>   How are they stored?  If they look like this:
> 
> -----BEGIN CERTIFICATE-----
> MIIGHDCCBASgAwIBAgICEBIwDQYJKoZIhvcNAQELBQAwgZMxCzAJBgNVBAYTAlVT
> MQswCQYDVQQIDAJGTDEcMBoGA1UECgwTQ29ubWFuIExhYm9yYXRvcmllczEaMBgG
> A1UECwwRU2VjdXJpdHkgRGl2aXNpb24xHzAdBgNVBAMMFkNvbm1hbiBMYWJvcmF0
> ...
> 
> then your figures are a bit high

They're DER encoded binary files, so no worries about that.

> 		size direction
> 	1	60 ->		SYN packet to server (no data)
> 	2	60 <-		SYN + ACK from server (still no data)
> 	3	52 ->		ACK from client (still no data)
> 	4	203 ->		initial client TLS request
> 	5	52 <-		ACK from server (no data)
> 	6	1492 <-		server certificate
> 	7	52 ->		ACK from client (no data)
> 	8	611 <-		TLS? unsure from this point on
> 	9	52 ->		ACK from client (no data)
> 	10	144 ->		data
> 	11	52 <-		ACK from server (no data)
> 	12	95 <-		data
> 	13	102 ->		data
> 	14	1492 <-		data (I'm assuming by now this is the file)
> 	15	1282 <-		data (probably more file)
> 	16	52 ->		ACK from client (no data)
> 	17	75 <-		getting ready to close?
> 	18	75 ->		getting ready to cloes?
> 	19	52 ->		FIN + ACK from client (no data)
> 	20	46 <-		FIN from server (no data)

Thanks for this, very enlightening!

Cheers,
Solderpunk