Unruly certificates cause a failure for the HTTPS endpoint in question. This should also apply to other TLS protocols (imaps, ftps, etc)
Failing is not unreasonable behavior but it might be useful to handle illegal ASN.1 more gracefully, perhaps silently ignoring any blobs that aren't technically legal but also do not break the entire stream
There are two approaches that come to mind, they aren't mutually exclusive:
Returning the valid portions of the ASN.1 via an opt-in "loose" argument at the highest level ASN.1 interface(s)
Investigate any known real-world cases that break the parser and see if they should be handled explicitly on a case-by-case basis. There's at least one example in the referenced zgrab2 issue but being 5 months old, it may no longer be available. I'm sure some other examples can be identified
I don't have time to look into this now and I can't even guess as whether the changes would have to be made inside ASN.1 parsing logic (blech) or via a higher level interface to ASN.1 parsing. I like to think there is a strict=false argument in some interface that causes unexpected objects to be quietly skipped but that may be too optimistic
Unless there are any objections I would like to leave the issue open, despite it not being a defect. Maybe someone else will have time to look at it, or maybe I'll come back when I have time
Thanks!
EDIT: this seems relevant to my interests... may be an easy task afterall
This is a placeholder for an issue reported in the zgrab2 issues @ https://github.com/zmap/zgrab2/issues/378 by @rony0724
Unruly certificates cause a failure for the HTTPS endpoint in question. This should also apply to other TLS protocols (imaps, ftps, etc)
Failing is not unreasonable behavior but it might be useful to handle illegal ASN.1 more gracefully, perhaps silently ignoring any blobs that aren't technically legal but also do not break the entire stream
There are two approaches that come to mind, they aren't mutually exclusive:
I don't have time to look into this now and I can't even guess as whether the changes would have to be made inside ASN.1 parsing logic (blech) or via a higher level interface to ASN.1 parsing. I like to think there is a strict=false argument in some interface that causes unexpected objects to be quietly skipped but that may be too optimistic
Unless there are any objections I would like to leave the issue open, despite it not being a defect. Maybe someone else will have time to look at it, or maybe I'll come back when I have time
Thanks!
EDIT: this seems relevant to my interests... may be an easy task afterall