OSCommerce Product Manager

OSCommerce Product Manager for Windows
Tasklist

FS#70 - PLink refuses connection to unknown hosts.

Attached to Project: OSCommerce Product Manager
Opened by Mario A. Valdez-Ramirez (mvaldez) - Saturday, 21 August 2004, 09:58 GMT-6
Last edited by Mario A. Valdez-Ramirez (mvaldez) - Friday, 26 August 2005, 22:01 GMT-6
Task Type Bug Report
Category Backend / Core
Status Closed
Assigned To Mario A. Valdez-Ramirez (mvaldez)
Operating System All
Severity Low
Priority Normal
Reported Version any
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

PLink, as all programs in the puTTY suit, refuses to connect to unknown hosts unless the user confirms the connection (at least for the first time). This is a security measure against a man-in-the-middle attack or spoofing attacks.

Currently, from within the OSCPMWin application, the only chance for the user to confirm the connection the first time is when using the "Check SSH connection" in the configuration dialog.

Should we automate this step so the application accepts by default any connection? If we do, the responsability of avoiding the mentionen attacks is on us. If we don't, the user will stay with the "Check SSH" button. Second option is ugly but it works. First option would allow us to intercept the queries of PLink and we can pass them to the user in a GUI-friendly fashion.

Pending to check options.
This task depends upon

Closed by  Mario A. Valdez-Ramirez (mvaldez)
Friday, 26 August 2005, 22:01 GMT-6
Reason for closing:  
Comment by Mario A. Valdez-Ramirez (mvaldez) - Saturday, 21 August 2004, 20:06 GMT-6
Capturing and parsing the output of PLink is a lot more complex than what we are doing to launch the PLink process. I'm changing priority of this to "Medium Low" but keep Severity in "Major".

Kind of incongruent, but logistical/technical difficulty is too high and there are more urgents fixes to do. Maybe later we can raise the Priority.
Comment by Mario A. Valdez-Ramirez (mvaldez) - Friday, 26 August 2005, 22:01 GMT-6

This bug is a duplicate.
The following bug addresses the same issue: #69, #70 and #194. The #194 is closed as fixed.

Closing this one.

Loading...