essentialkaos/sslscan

Go package for working with SSLLabs API

Installation • Build Status • Contributing • Terms of Use • License

Package for Go for working with SSLLabs public API.

Installation

To build the SSLScan from scratch, make sure you have a working Go 1.18+ workspace (instructions), then:

go get -u github.com/essentialkaos/sslscan/v13

Build Status

Branch	Status
master
develop

Contributing

Before contributing to this project please read our Contributing Guidelines.

Terms of Use

This project is not affiliated with SSL Labs and not officially supported by SSL Labs. Before using this package please read Qualys SSL Labs Terms of Use.

Also you should:

• Only inspect sites and servers whose owners have given you permission to do so;
• Be clear that this tool works by sending assessment requests to remote SSL Labs servers and that this information will be shared with them.

License

Apache License, Version 2.0

sslscan's Issues

Feature request: context instead of timeouts

Before opening an issue, search for similar bug reports or feature requests on GitHub Issues. If yes, please add a 👍 reaction to the existing issue. If no similar issue can be found, fill out either the "Bug Report" or the "Feature Request" section below. Erase the other section and everything on and above this line.

Feature Request

Opening a feature request kicks off a discussion. Requests may be closed if we're not actively planning to work on them.

Proposal:

fasthttp.Client implements DoDeadline (https://github.com/valyala/fasthttp/blob/56775f4d9fa114edf7f860abfe95294b58e61020/client.go#L2241)

How about changing api of Analyze, Info, and GetEndpointInfo so that all of them accepted context.Context, and then context.Context.Deadline() is used to obtain the client operation deadline.

Current behavior:

It's hardcoded to 10 seconds at

sslscan/sslscan.go

Line 510 in c78b03e

var RequestTimeout = 10.0

Desired behavior:

I think it would be more in line with general clients expectations: when a caller provides timeout/deadline expectations

Use case:

In case if the caller side does not want results anymore - no need to retain resources (memory and sockets) for more than necessary, and make the caller wait for up to extra 10 seconds.

I'm ready to implement it we agree on the implementation details and project owner vision.

Feature request: typed error for non-http-200 responses

Before opening an issue, search for similar bug reports or feature requests on GitHub Issues. If yes, please add a 👍 reaction to the existing issue. If no similar issue can be found, fill out either the "Bug Report" or the "Feature Request" section below. Erase the other section and everything on and above this line.

Feature Request

Opening a feature request kicks off a discussion. Requests may be closed if we're not actively planning to work on them.

Proposal:

Typed errors for different response types for ease of handling it

Current behavior:

At the moment non-http-200 responses trigger a generic string error

sslscan/sslscan.go

Lines 641 to 645 in c78b03e

	statusCode := resp.StatusCode()
	if statusCode != 200 {
	return fmt.Errorf("API return HTTP code %d", statusCode)
	}

Which means if a caller wants to handle different responses differently - eg: wait significantly longer for 529 they need to parse text error.

What if a dedicated type HttpError was introduced, which held status code (and may be even the response body).

Desired behavior:

Have easier way to assert if it was http error, or something else.

Use case:

Depending on http status codes the caller actions might be different. At the moment it's required to parse error string to extract the status code value.

I'm ready to implement it we agree on the implementation details and project owner vision.

Panic due to nil pointer in `Analyze`

The Analyze function crashes due to nil pointer.

Stack Trace:

runtime error: invalid memory address or nil pointer dereference
Full Stack Trace
  github.com/essentialkaos/sslscan/v13.(*API).doRequest(0x0, {0xc000f92000, 0x90}, {0x0, 0x0})
    /tmp/go/pkg/mod/github.com/essentialkaos/sslscan/[email protected]/sslscan.go:650 +0x1da
  github.com/essentialkaos/sslscan/v13.(*API).Analyze(0x0, {0xc000cbb4a0, 0x2a}, {0x0, 0x0, 0x0, 0x0, 0x0})
    /tmp/go/pkg/mod/github.com/essentialkaos/sslscan/[email protected]/sslscan.go:563 +0x152

Bug report

System info:

• Version used: v13.1.1
• OS (e.g. from /etc/*-release): Linux
• Kernel (uname -a):
• Go version (go version): 1.17
• Install tools: Go

Steps to reproduce:

Happens sporadically

Expected behavior:

Work without crashing

Actual behavior:

Crashes

Additional info:

That's the API we create (adding a custom DNS resolver):

api, err := sslscanv13.NewAPI("SSLScanTester", "10.0.2")
if err != nil || api == nil {
	return nil, err
}

api.RequestTimeout = 5 * time.Minute
api.Client.Dial = (&fasthttp.TCPDialer{
	Concurrency:      4096,
	DNSCacheDuration: time.Hour,
	Resolver: &net.Resolver{
		PreferGo: true,
		Dial: func(ctx context.Context, network, address string) (net.Conn, error) {
			d := net.Dialer{
				Timeout: time.Millisecond * time.Duration(10000),
			}
			return d.DialContext(ctx, network, nameServer)
		},
	},
}).Dial

And then this crashes, let's say once in ~50 runs:

progress, err = api.Analyze(host, sslscanv13.AnalyzeParams{})

---

Feature Request

Opening a feature request kicks off a discussion. Requests may be closed if we're not actively planning to work on them.

Proposal:

[Description of the feature]

Current behavior:

[What currently happens]

Desired behavior:

[What you would like to happen]

Use case:

[Why is this important (helps with prioritizing requests)]