Re: [GTALUG] Script to show HTTP(S) and TLS details for a website

[David Mason via talk]

Line 130 s/-eq/=/

Otherwise, cool! Thanks!

../Dave
On Aug 10, 2019, 5:32 PM -0400, Jason Shaw via talk , wrote:
> Looks like a handy script to have.  My only real suggestion is to change the 
> shebang to
> #!/usr/bin/env bash
> as it's more portable than the current one.  Still not perfect, but works 
> reliably on more systems.
>
> -jason
>
> > On Sat, Aug 10, 2019 at 11:46 AM Giles Orr via talk  wrote:
> > > This may be seen as self-promotion - that's not totally wrong.  But I 
> > > think this may also be useful to others and (as I acknowledge in the blog 
> > > post) I'm quite pleased with the resultant script.
> > >
> > > Over the past year and a half I've slowly developed a shell script that 
> > > gives a concise summary of the state of TLS and HTTP(S) on a given 
> > > website.  It looks like this:
> > >
> > >     $ tlsdetails google.ca
> > >     Using OpenSSL:  /usr/bin/openssl
> > >     Expiry Date:    Oct 27 17:27:07 2019 GMT (78 days)
> > >     Issuer:         Google Trust Services, CN
> > >     TLS Versions:   tls1_3 tls1_2 tls1_1 tls1  (tried but unavailable: 
> > > ssl3 ssl2 )
> > >     HTTP Version:   2
> > >
> > > I first started work on it after a couple embarrassing certificate 
> > > expiries.  It then grew to check the Issuer, TLS versions, and more 
> > > recently whether or not a site supports HTTP2.
> > >
> > > (The pointer to the OpenSSL version is shown because the script will also 
> > > run on Mac, and their version of 'openssl' is problematic at best.  That 
> > > line is of course easy to remove if you don't like it.)
> > >
> > > If you're interested, you can find the details here:
> > >
> > > https://www.gilesorr.com/blog/tls-https-details.html
> > >
> > > Any suggestions to improve the script would be most welcome.
> > >
> > > --
> > > Giles
> > > https://www.gilesorr.com/
> > > giles...@gmail.com
> > > ---
> > > Post to this mailing list talk@gtalug.org
> > > Unsubscribe from this mailing list 
> > > https://gtalug.org/mailman/listinfo/talk
> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] Script to show HTTP(S) and TLS details for a website

[Jason Shaw via talk]

Looks like a handy script to have.  My only real suggestion is to change
the shebang to
*#!/usr/bin/env bash*
as it's more portable than the current one.  Still not perfect, but works
reliably on more systems.

-jason

On Sat, Aug 10, 2019 at 11:46 AM Giles Orr via talk  wrote:

> This may be seen as self-promotion - that's not totally wrong.  But I
> think this may also be useful to others and (as I acknowledge in the blog
> post) I'm quite pleased with the resultant script.
>
> Over the past year and a half I've slowly developed a shell script that
> gives a concise summary of the state of TLS and HTTP(S) on a given
> website.  It looks like this:
>
> $ tlsdetails google.ca
> Using OpenSSL:  /usr/bin/openssl
> Expiry Date:Oct 27 17:27:07 2019 GMT (78 days)
> Issuer: Google Trust Services, CN
> TLS Versions:   tls1_3 tls1_2 tls1_1 tls1  (tried but unavailable:
> ssl3 ssl2 )
> HTTP Version:   2
>
> I first started work on it after a couple embarrassing certificate
> expiries.  It then grew to check the Issuer, TLS versions, and more
> recently whether or not a site supports HTTP2.
>
> (The pointer to the OpenSSL version is shown because the script will also
> run on Mac, and their version of 'openssl' is problematic at best.  That
> line is of course easy to remove if you don't like it.)
>
> If you're interested, you can find the details here:
>
> https://www.gilesorr.com/blog/tls-https-details.html
>
> Any suggestions to improve the script would be most welcome.
>
> --
> Giles
> https://www.gilesorr.com/
> giles...@gmail.com
> ---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list
> https://gtalug.org/mailman/listinfo/talk
>
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] War Story: Asus UX305ca SSD failures

[James Knott via talk]

On 2019-08-10 12:52 PM, Russell Reiter via talk wrote:
> While the author of the link below lambasted Open Source Cheapskates,
> the demise of the Linux Journal speaks to that effect on users of
> Linux. I never subscribed, but I picked up a copy now and then, or
> browsed it at the library.

I subscribed for several years, but then Sean Powers took over as editor
and it became less interesting.  I still maintained my subscription,
until the paper version ended.

---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] War Story: Asus UX305ca SSD failures

[Russell Reiter via talk]

On Sat, Aug 10, 2019, 10:39 AM D. Hugh Redelmeier via talk 
wrote:

> | From: Alvin Starr via talk 
>
> | It would be interesting to see the bit densities over time from stone
> | tablets(how would cave paintings count?)  to the latest production
> storage
> | systems.
> | It would also be interesting to know how many people had access to the
> storage
> | media over time. That would have started with a few priests and specially
> | trained people to just about everybody having a cell phone with a few GB
> of
> | storage.
>
> Yeah.  The main reason for new formats is that they are cheaper or
> larger. Sadly not because of endurance.
>
> One McLuhan-esqe observation is that what gets recorded on new media
> is likely less significant / important.  My brother often remarks that
> that photos on film (or glass and metal plates!) were way more
> considered and significant than photos now.  We are buried in snaps
> and will need AI to find ones that we might actually be interested in
> later.
>

Another emerging media issue is that; as the cost of delivering the media
content starts to converge with zero, so is the value of that written
content lessening.

While the author of the link below lambasted Open Source Cheapskates, the
demise of the Linux Journal speaks to that effect on users of Linux. I
never subscribed, but I picked up a copy now and then, or browsed it at the
library.

 https://betanews.com/2019/08/08/linux-journal-dies-again-rip/

All print media is feeling the digital crunch and while everyone is now
able to publish on the net, in whatever fashion they choose, it is nice to
have authentic curation of information. That too will probably require some
kind of AI in the not to distant future. A masthead on a broadsheet was an
emblem of credibility. On the web it appears under the sponsoring message
of the day.

>
> A separate problem is that we often don't know how useful or
> interesting something is until later.  I imagine that to collectors
> TV Guide is more precious than National Geographic since nobody saved
> the former and everybody saved the latter.
>
> (It is thought that the NSA is buried in data with insufficient means
> to find even the obviously interesting stuff.)
>
>
> | From: James Knott via talk 
>
> | On 2019-08-09 01:19 PM, Russell Reiter wrote:
> | > Jpegs are an exported file format created from aggregated image data
> | > collected by the CCD. They are digital files and subject to
> | > transmission errors just like any other signal. My 13 megapixel phone
> | > saves image data directly as a jpg file. Sure the raw data has been
> | > manipulated before writing the original, but that is much different
> | > than having an image recorded using raw format and then exporting a
> | > copy in a lossy format in order to save space.
>
> In cameras, it seems to be called RAW, not raw.  I think that is to
> remind us that each camera has its own proprietary format.  Only
> sometimes is the format disclosed.
>
> Worse: some cameras never have a raw image: they convert to JPEG on
> the fly since their storage has neither the bandwidth or capacity to
> store a whole raw image.
>
> | Perhaps you need to learn about some of the technology.  Some media,
> | such as CDs & DVDs use forward error correction, to ensure data is
> | copied correctly.
>
> A significant number of problems cannot be corrected by FEC.  In
> particular, misplacing a CD or having a 100% failure in an SSD (the
> original problem that prompted the thread).
>
> |   When you transfer data over a network, there is a
> | checksum used with TCP, with IP(v4) and a CRC check at the Ethernet
> | level.  On top of that some applications provide their own integrity
> | check.  So, it would be very difficult for an error to propagate.  Now,
>
> An excuse to roll out another story.
>
> When I was trying to make my Altair useful, I wrote a monitor.  I
> needed a way of doing integrity checks for files recorded to audio
> tape and files sent over a serial line.  I decided that CRC16 was way
> better than a simple XOR checksum.  I looked into it and devised a way
> of calculating CRCs in software by byte-at-a-time operations rather
> than bit at a time (CRC was designed to be implemented in hardware,
> bit-wise, with a linear-feedback shift register).
>
> I wrote the code in 8080 assembler and in C.
>
> I released the code on usenet (no, not all of usenet was porn).
>
> Unbknownst to me, my code made it into the RFCs for PPP.  Open source
> works.  
>
> BTW, CRC isn't any good at detecting forgeries.  For that we have
> cryptographic hashes.  And those hashes need to be protected against
> forgery too (digital signatures or another secure communications
> channel).---
> Post to this mailing list talk@gtalug.org
> Unsubscribe from this mailing list
> https://gtalug.org/mailman/listinfo/talk
>
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list 

[GTALUG] Script to show HTTP(S) and TLS details for a website

[Giles Orr via talk]

This may be seen as self-promotion - that's not totally wrong.  But I think
this may also be useful to others and (as I acknowledge in the blog post)
I'm quite pleased with the resultant script.

Over the past year and a half I've slowly developed a shell script that
gives a concise summary of the state of TLS and HTTP(S) on a given
website.  It looks like this:

$ tlsdetails google.ca
Using OpenSSL:  /usr/bin/openssl
Expiry Date:Oct 27 17:27:07 2019 GMT (78 days)
Issuer: Google Trust Services, CN
TLS Versions:   tls1_3 tls1_2 tls1_1 tls1  (tried but unavailable: ssl3
ssl2 )
HTTP Version:   2

I first started work on it after a couple embarrassing certificate
expiries.  It then grew to check the Issuer, TLS versions, and more
recently whether or not a site supports HTTP2.

(The pointer to the OpenSSL version is shown because the script will also
run on Mac, and their version of 'openssl' is problematic at best.  That
line is of course easy to remove if you don't like it.)

If you're interested, you can find the details here:

https://www.gilesorr.com/blog/tls-https-details.html

Any suggestions to improve the script would be most welcome.

-- 
Giles
https://www.gilesorr.com/
giles...@gmail.com
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] War Story: Asus UX305ca SSD failures

[D. Hugh Redelmeier via talk]

| From: Alvin Starr via talk 

| The old 78RPM recordings were made of a shellac material that I believe was
| more resilient than vinyl but both the masters and produced records were
| subject to degradation with use.

I gave away my grandmother's 78s to someone who promised to digitize
them and give me a copy.  That has yet to happen.

The needles in 78s are quite different from 33 RPM LPs.  Much cruder.
They were typically steel or cactus thorns!

Mixed in with the shellac was an abrasive, intended to keep the needle
sharp!  Imagine where the filings ended up!

In the stereo LP world, great care was taken to avoid anything
abrasive.  The needles were made of very hard materials like diamond.
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] War Story: Asus UX305ca SSD failures

[D. Hugh Redelmeier via talk]

| From: Alvin Starr via talk 

| It would be interesting to see the bit densities over time from stone
| tablets(how would cave paintings count?)  to the latest production storage
| systems.
| It would also be interesting to know how many people had access to the storage
| media over time. That would have started with a few priests and specially
| trained people to just about everybody having a cell phone with a few GB of
| storage.

Yeah.  The main reason for new formats is that they are cheaper or
larger. Sadly not because of endurance.

One McLuhan-esqe observation is that what gets recorded on new media
is likely less significant / important.  My brother often remarks that
that photos on film (or glass and metal plates!) were way more
considered and significant than photos now.  We are buried in snaps
and will need AI to find ones that we might actually be interested in
later.

A separate problem is that we often don't know how useful or
interesting something is until later.  I imagine that to collectors
TV Guide is more precious than National Geographic since nobody saved
the former and everybody saved the latter.

(It is thought that the NSA is buried in data with insufficient means
to find even the obviously interesting stuff.)


| From: James Knott via talk 

| On 2019-08-09 01:19 PM, Russell Reiter wrote:
| > Jpegs are an exported file format created from aggregated image data
| > collected by the CCD. They are digital files and subject to
| > transmission errors just like any other signal. My 13 megapixel phone
| > saves image data directly as a jpg file. Sure the raw data has been
| > manipulated before writing the original, but that is much different
| > than having an image recorded using raw format and then exporting a
| > copy in a lossy format in order to save space. 

In cameras, it seems to be called RAW, not raw.  I think that is to
remind us that each camera has its own proprietary format.  Only
sometimes is the format disclosed.

Worse: some cameras never have a raw image: they convert to JPEG on
the fly since their storage has neither the bandwidth or capacity to
store a whole raw image.

| Perhaps you need to learn about some of the technology.  Some media,
| such as CDs & DVDs use forward error correction, to ensure data is
| copied correctly.

A significant number of problems cannot be corrected by FEC.  In
particular, misplacing a CD or having a 100% failure in an SSD (the
original problem that prompted the thread).

|   When you transfer data over a network, there is a
| checksum used with TCP, with IP(v4) and a CRC check at the Ethernet
| level.  On top of that some applications provide their own integrity
| check.  So, it would be very difficult for an error to propagate.  Now,

An excuse to roll out another story.

When I was trying to make my Altair useful, I wrote a monitor.  I
needed a way of doing integrity checks for files recorded to audio
tape and files sent over a serial line.  I decided that CRC16 was way
better than a simple XOR checksum.  I looked into it and devised a way
of calculating CRCs in software by byte-at-a-time operations rather
than bit at a time (CRC was designed to be implemented in hardware,
bit-wise, with a linear-feedback shift register).

I wrote the code in 8080 assembler and in C.

I released the code on usenet (no, not all of usenet was porn).

Unbknownst to me, my code made it into the RFCs for PPP.  Open source
works.  

BTW, CRC isn't any good at detecting forgeries.  For that we have
cryptographic hashes.  And those hashes need to be protected against
forgery too (digital signatures or another secure communications channel).---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk