Skip to content

TLS prototype#4003

Draft
End-rey wants to merge 2 commits into
masterfrom
mtls
Draft

TLS prototype#4003
End-rey wants to merge 2 commits into
masterfrom
mtls

Conversation

@End-rey
Copy link
Copy Markdown
Contributor

@End-rey End-rey commented May 29, 2026

Closes #4001.

@codecov
Copy link
Copy Markdown

codecov Bot commented May 29, 2026

Codecov Report

❌ Patch coverage is 5.26316% with 180 lines in your changes missing coverage. Please review.
✅ Project coverage is 27.72%. Comparing base (3b4a1dd) to head (2562a45).

Files with missing lines Patch % Lines
cmd/neofs-node/mtls.go 0.00% 72 Missing ⚠️
pkg/services/object/server.go 22.72% 28 Missing and 6 partials ⚠️
pkg/network/cache/clients.go 0.00% 31 Missing ⚠️
pkg/network/peerauth/peerauth.go 0.00% 30 Missing ⚠️
cmd/neofs-node/grpc.go 0.00% 7 Missing ⚠️
cmd/neofs-node/config.go 0.00% 6 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #4003      +/-   ##
==========================================
- Coverage   27.80%   27.72%   -0.09%     
==========================================
  Files         681      683       +2     
  Lines       46758    46896     +138     
==========================================
- Hits        13003    13000       -3     
- Misses      32517    32652     +135     
- Partials     1238     1244       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

End-rey added 2 commits June 3, 2026 23:20
Storage nodes authenticate to each other with mutual TLS over their existing
public gRPC port. A node dials with a sentinel SNI and is served the identity
certificate, verified against the network map; clients keep getting the plain
or server-TLS endpoint unchanged. Peers are pinned by their network-map key.

Signed-off-by: Andrey Butusov <andrey@nspcc.io>
On the inter-node mTLS listener the peer is an authenticated network-map node,
so verifying the per-request signature and signing the response are redundant
for 1:1 (TTL<=1) hops and are skipped. Requests arriving on the plain public
listener carry no TLS peer certificate and are always verified and signed, so
clients remain unaffected.

Signed-off-by: Andrey Butusov <andrey@nspcc.io>
@End-rey
Copy link
Copy Markdown
Contributor Author

End-rey commented Jun 4, 2026

Benchmark tests were run on this branch against the 0.53 release. Throughput in ops/s. Very nice improvement for small objects, where the per-message signature dominates and the 1:1-hop skip removes it; large objects are bandwidth-bound, so any difference there is within the test's margin of error (no regression).

REP3

Test Size, KB Threads base mTLS Δ
PUT 4 1 235 241 +3%
PUT 4 4 694 751 +8%
PUT 4 16 998 1186 +19%
PUT 4096 1 89 88 −1%
PUT 4096 4 171 170 −1%
PUT 4096 16 210 202 −4%
GET 4 1 1477 2217 +50%
GET 4 4 2353 4373 +86%
GET 4 16 2877 6142 +114%
GET 4096 1 323 345 +7%
GET 4096 4 535 575 +7%
GET 4096 16 613 669 +9%

EC6+2

Test Size, KB Threads base mTLS Δ
PUT 4 1 152 167 +10%
PUT 4 4 303 369 +22%
PUT 4 16 271 316 +17%
PUT 4096 1 86 92 +7%
PUT 4096 4 142 160 +13%
PUT 4096 16 173 166 −4%
GET 4 1 1338 1655 +24%
GET 4 4 2309 3246 +41%
GET 4 16 1240 (4683 err) 2301 (8646 err) +86%
GET 4096 1 295 353 +20%
GET 4096 4 443 492 +11%
GET 4096 16 479 (425 err) 547 (509 err) +14%

@cthulhu-rider
Copy link
Copy Markdown
Contributor

very visible improvement for smaller data 🚀

it seems to me that this approach can be extended to user-SN connections too. If so, we can expect additional performance gains. Are there any blockers? (not for this PR)

@cthulhu-rider
Copy link
Copy Markdown
Contributor

it should also be noted that EC GET code has not been touched yet. Tested version includes #3996 improvement, that's why we see 📈. It may become even faster with same TLS optimization

@End-rey
Copy link
Copy Markdown
Contributor Author

End-rey commented Jun 5, 2026

it seems to me that this approach can be extended to user-SN connections too. If so, we can expect additional performance gains. Are there any blockers? (not for this PR)

Yes, it can extend to client-SN and would help the read path. In my opinion two problems, though: client authorization can take a trickier path than node-to-node, and it may not be possible to cover all requests this way (but that's not for sure). Worth exploring, but not a drop-in like the node-to-node case.

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.

TLS-only prototype

2 participants