Skip to content

Conversation

@notroj
Copy link
Collaborator

@notroj notroj commented Oct 20, 2025

Draft: Add SSLVHostSNIPolicy directive, which sets a global policy for SSL configuration compatibility between VirtualHosts.

Usage: SSLVHostSNIPolicy <policy> where policy must be one of:

  • strict => fail for any vhost mismatch
  • authonly => fail only for client verification/auth differences
  • secure => fail as authonly plus ciphersuite, protocol, keypair differences
  • insecure => allow everything

"secure" is the default.

PR: 69743

@notroj notroj changed the title Draft: Add SSLVHostSNIPolicy directive, which sets a global Draft: Add SSLVHostSNIPolicy directive Oct 20, 2025
@notroj
Copy link
Collaborator Author

notroj commented Oct 20, 2025

We could actually eliminate all the runtime complexity by computing and storing a hash for each SSLSrvConfigRec based on the policy mode in e.g. ssl_init_CheckServers, then just compare that at runtime. Am I overthinking?

@notroj notroj force-pushed the ssl-vhost-sni-policy branch from e0b5a2f to a504301 Compare October 20, 2025 20:48
hash_ssl_params(a1, dig1);
hash_ssl_params(a2, dig2);

return strcmp((char *)dig1, (char *)dig2) == 0;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are dig1 and dig2 null terminated strings that do not contain any nulls inside or do we need to do a memcmp(dig1, dig2, APR_MD5_DIGESTSIZE) instead of the strcmp?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point!


apr_md5_update(&ctx, p->name, strlen(p->name));
apr_md5_update(&ctx, "##", 2);
apr_md5_update(&ctx, p->value, strlen(p->value));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does a different ordering of the same key value pairs in the array mean a different configuration?
Won't the hashes be different if the arrays are the same but have a different ordering of the key value pairs?
Hence wouldn't we need to sort the arrays first prior to hashing? e.g.

  1. Transform the original array into an array that contains name + '##' + value as strings
  2. Sort the new array
  3. Hash the new array as above

@rpluem
Copy link
Collaborator

rpluem commented Oct 21, 2025

We could actually eliminate all the runtime complexity by computing and storing a hash for each SSLSrvConfigRec based on the policy mode in e.g. ssl_init_CheckServers, then just compare that at runtime. Am I overthinking?

This sounds like a very good idea, but see my comments on the updated code.

@notroj
Copy link
Collaborator Author

notroj commented Oct 21, 2025

I'll try rewriting it to use hashes.

For SSLOpenSSLConfCmd - I think semantically it's better to treat this as a list of commands, because that's exactly how it's executed. Sorting would assume the interpretation is indifferent to the order, but e.g. Options it is simply flipping bits in the bitmask for each SSL_CONF_cmd call so the order is significant.

  SSLOpenSSLConfCmd Options -EmptyFragments
  SSLOpenSSLConfCmd Options EmptyFragments

would have different semantics to the inverse order.

@rpluem
Copy link
Collaborator

rpluem commented Oct 21, 2025

I'll try rewriting it to use hashes.

For SSLOpenSSLConfCmd - I think semantically it's better to treat this as a list of commands, because that's exactly how it's executed. Sorting would assume the interpretation is indifferent to the order, but e.g. Options it is simply flipping bits in the bitmask for each SSL_CONF_cmd call so the order is significant.

  SSLOpenSSLConfCmd Options -EmptyFragments
  SSLOpenSSLConfCmd Options EmptyFragments

would have different semantics to the inverse order.

If order matters than all should be good with the current approach. What about the memcmp vs strcmp?

@notroj
Copy link
Collaborator Author

notroj commented Oct 21, 2025

Definitely will switch to using memcmp to compare the digests

policy for SSL configuration compatibility between VirtualHosts.

 SSLVHostSNIPolicy
    strict   => fail for any vhost mismatch
    authonly => fail only for client verification/auth differences
    secure   => fail as authonly plus ciphersuite, protocol, keypair diff
    insecure => allow everything

"secure" is the default.

PR: 69743
@notroj notroj force-pushed the ssl-vhost-sni-policy branch from a504301 to 15234fa Compare October 21, 2025 16:15
@notroj
Copy link
Collaborator Author

notroj commented Oct 21, 2025

Switched to converting the digest to ASCII hex and using strcmp because it was easier for debugging for now. Still PoC but it passes my tests and the runtime code is a lot simpler now. 😉

@rpluem
Copy link
Collaborator

rpluem commented Oct 22, 2025

Looks good

Copy link
Member

@ylavic ylavic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, looks good to me too.

@notroj notroj deleted the ssl-vhost-sni-policy branch October 23, 2025 18:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants