>> Found that some of below are indeed able to hang the regex stack (e.g. # 2).
>> However the more elaborate regex-es are blocked by:
>>
>> private final static Pattern WILDCARD_PATTERN = Pattern.compile(
>> "^[a-z0-9\\-\\*]+(\\.[a-z0-9\\-]+){2,}$", Pattern.CASE_INSENSITIVE);
>> ..
>> WILDCARD_PATTERN.matcher(identity).matches()
>>
>> which we apply to the subjectAltName, CN, etc. So that is not too bad then -
>> assuming that that regep does not let them through. Which is likely - as the
>> only dangerous thing I see in there is a *.
>>
>
> Thank you so much for your feedback. What I could do is validate both
> the identity and the subjectAltName pattern by making sure they consist
> of characters legal for domain names (alphanumeric, dash and asterisk in
> case of subjectAltName) prior to doing regexp matching with them.
Right - but I am wondering if that means we end up in a rear guard battle. As
we then find IPv6 addresses containing ‚:’ and god knows what new TLDs may do
5+ years hence.
Now *all* that is allowed are ‚*’ — and as far as I know - only in string (and
not IPv4/IPv6) based entries.
So perhaps it is an option to compare things from the TLD down with a very very
simple loop.
if (starts with a star) then
@a = array of FQDN split on ‚.'
@b = array of FQDN split on ‚.’
if not right lenghts - bail
working from the topmost side working to last but one
bail if not the same.
check if we have left just one entry on a and a wildcard on b.
i.e. avoid wildcards completely.
> Obviously - as we get into UTF8 internationalized domain names - we may
> accidentally break that protection at some point.
>
> Would not internationalized domain names be Punycode encoded instead?
Yes - but I am worried about the easy to make mistakes; and the lack of
normalization* some people my accidentally not apply. The CA’s do not have a
good track record.
But none of this is very urgent/key - just more a robustness thing.
Dw.
*: e.g. things like invisible unicode chars to do a ‚backspace’ or visually
wipe text.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
