- 
                Notifications
    
You must be signed in to change notification settings  - Fork 39
 
implement keysize mismatch #197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
c053983    to
    bbb0c33      
    Compare
  
    79928b5    to
    78f4ed7      
    Compare
  
    
          Codecov ReportAll modified and coverable lines are covered by tests ✅ 
 
 Additional details and impacted files@@            Coverage Diff             @@
##             main     #197      +/-   ##
==========================================
- Coverage   77.54%   75.84%   -1.70%     
==========================================
  Files          85       88       +3     
  Lines       14000    14287     +287     
==========================================
- Hits        10856    10836      -20     
- Misses       3144     3451     +307     ☔ View full report in Codecov by Sentry.  | 
    
| warn!("Key size mismatch: caller requested {:?}, listener was configured with {:?}. Selecting {:?}", incoming.key_size, key_settings.key_size, incoming.key_size); | ||
| key_settings.key_size = incoming.key_size; | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this intended behavior? If my understanding is correct, this means the client can change the server's encryption settings to what it wants.
It can even set the key size to 0, but thankfully that is then caught here by defaulting to Bytes16 instead of no encryption at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me confirm what the ref impl does...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, it seems to base it off SRTO_SENDER
https://github.com/haivision/srt/blob/39822840c506d72cef5a742d28f32ea28e144345/srtcore/core.cpp#L4927
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't currently implement SRTO_SENDER because it is only really needed for old SRT compatibility (new SRT is always full duplex). However the docs say that this is the only modern use of it https://github.com/Haivision/srt/blob/master/docs/API/API-socket-options.md#SRTO_SENDER
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For example:
$ srt-live-transmit "srt://:2222?pbkeylen=24&passphrase=password123" udp://127.0.0.1:3333 -a:no &
$ srt-live-transmit udp://:1111 "srt://127.0.0.1:2222?passphrase=password123&pbkeylen=16" -a:no
18:55:59.730216/SRT:RcvQ:w1!W:SRT.cn: processConnectResponse: PBKEYLEN conflict - keep 16; peer-advertised PBKEYLEN 24 rejected because Agent is SRTO_SENDER
$ srt-live-transmit udp://:1111 "srt://:2222?passphrase=password123&pbkeylen=16" -a:no &
$ srt-live-transmit "srt://127.0.0.1:2222?pbkeylen=24&passphrase=password123" udp://127.0.0.1:3333 -a:no
18:57:28.338138/SRT:RcvQ:w1!W:SRT.cn: processConnectResponse: PBKEYLEN conflict - OVERRIDDEN 24 by 16 from PEER (as AGENT is not SRTO_SENDER)
Fixes #195