|
Audience:
|
Excuse me, I had a question about access via telnet to the ascii OPAC.
|
|
Presenter:
|
Yeah, I figured somebody was going to bring that up. Go ahead.
|
|
Audience:
|
Don't ascii OPAC users also transmit and receive personal information?
|
|
Presenter:
|
Yes they do.
|
|
Audience:
|
But I thought telnet was not secure.
|
|
Presenter:
|
That's correct.
|
|
Audience:
|
Well doesn't that raise the same issues as insecure HTTP transactions?
|
|
Presenter:
|
Yes it does. The exact same logic applies.
|
|
Audience:
|
If that's the case, what does your library do about it?
|
|
Presenter:
|
Us? We ignore it and hope nobody makes an issue of it.
|
|
Audience:
|
After explaining why we should use SSL, isn't that being more than a little hypocritical?
|
|
Presenter:
|
Essentially.
|
|
Audience:
|
But isn't there an SSL equivalent for telnet?
|
|
Presenter:
|
Yes there is. It's called Secure Shell (SSH).
|
|
Audience:
|
Okay, so why not use that?
|
|
Presenter:
|
From a purely technical standpoint, Secure Shell is a good solution. It provides the same point-to-point encryption for a login session that SSL provides for a web session. As a practical matter there are some non-trivial implementation issues.
|
|
Audience:
|
Could you elaborate?
|
|
Presenter:
|
Installing the server portion of Secure Shell is actually easier than installing SSL. But whereas browsers come encryption-ready, the client end of Secure Shell would have to be distributed to patrons. There are some other issues, but distributing and supporting clients is the main one.
|
|
Audience:
|
But what if a library still wanted to, or were required to, provide a secure ascii OPAC?
|
|
Presenter:
|
The first hurdle is making ascii OPAC users aware of the secure alternative to telnet and directing them to where they can get Secure Shell clients and technical support. The more robust Windows clients are commercial products, but there are also some open source clients.
|
|
Audience:
|
What's the best way to get the word out to users of the ascii OPAC?
|
|
Presenter:
|
At point of use. Ideally, selecting Patron Information in ascii OPAC would return a screen stating that transactions are not secure without special clients. That screen should also be customizable by libraries so that if they choose to support Secure Shell access, they could direct patrons appropriately.
|
|
Audience:
|
Are we likely to see that enhancement in a future version?
|
|
Presenter:
|
Probably not. Ascii OPAC is the red-headed stepchild of Voyager clients and doesn't get much, if any, development attention.
|
