[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Server Name Indication?
Thanks Ted and Thomas for your research.
Here are my thoughts:
1) Adding the constants to GSKSSL_H is no big deal, of course. But,
I'll need to know which
2) This won't be supported on older releases of IBM i, so we'll need to
figure out how to handle that. My thinking is that we would just call
gsk_set_attribute_buffer() and ignore any errors it returns. Older
systems that don't include this functionality could just ignore it.
(We'd log it to the debug log, though, in case someone had problems due
to this, then we could see what's going on..)
3) It looks to me that the difference between
GSK_SSL_EXTN_SERVERNAME_CRITICAL_REQUEST and
GSK_SSL_EXTN_SERVERNAME_REQUEST is that the 'CRITICAL' one will fail to
connect to any server that does not use SNI. So, it seems to me that
we should use the non-critical one in HTTPAPI, unless there's a reason
that we want to force the use of SNI (which I don't think would be a
good default, but could be enabled by the caller by calling a
http_force_sni() procedure or something like that.) Is there a
situation where forcing this to be 'critical' is important?
4) I don't like the idea of adding this to https_init(), because
https_init() establishes an environment for use in multiple HTTP
requests (to different servers). It seems to me that this is more
appropriate to CommSSL_Upgrade(). Will that work? Or can this only
be set at the environment level?
-SK
On 1/15/2014 2:01 AM, [1]thomas.raddatz@xxxxxx wrote:
Ted,
I found a discussion about SNI at "Bugzilla@Mozilla" where "Server name
indicatoin" was first mentioned in 2002. So it seems to be older that
expected:
[1][2]https://bugzilla.mozilla.org/show_bug.cgi?id=116168
The following blog entry anounces SNI for IE7 back in 2005:
[2][3]http://blogs.msdn.com/b/ie/archive/2005/10/22/483795.aspx
Next I found RFC 3546, which describes how to add extensions to the
client "Hello" message:
[3][4]http://www.ietf.org/rfc/rfc3546.txt
Last but not least here is a Wireshark trace of Firefox 20 connecting
to "email.1und1.de". As you can see, Firefox immediately sends the
server name extension, because it can safely assume that current
servers properly ignore unsupported (unkown) "Hello" extensions:
HTTP 260 CONNECT email.1und1.de:443 HTTP/1.1
HTTP 260 GET [4][5]http://http.xxx.xxx.xxx.xxx/xxx/ HTTP/1.1
HTTP 216 HTTP/1.1 200 OK
HTTP 105 HTTP/1.1 200 Connection established
TLSv1 237 Client Hello
Secure Sockets Layer
TLSv1 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 166
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 162
Version: TLS 1.0 (0x0301)
Random
Session ID Length: 0
Cipher Suites Length: 72
Cipher Suites (36 suites)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 49
Extension: server_name
Type: server_name (0x0000)
Length: 19
Server Name Indication extension
Extension: elliptic_curves
Extension: ec_point_formats
Extension: SessionTicket TLS
Extension: next_protocol_negotiation
TLSv1 1414 Server Hello
TLSv1 716 Certificate
TLSv1 264 Client Key Exchange, Change Cipher Spec,
Encrypted Handshake Message
TLSv1 348 New Session Ticket, Change Cipher Spec,
Encrypted Handshake Message
OCSP 567 Request
HTTP 260 GET [5][6]http://http.xxx.xxx.xxx.xxx/xxx/ HTTP/1.1
HTTP 215 HTTP/1.1 200 OK
OCSP 476 Response
TLSv1 1676 Application Data, Application Data
TLSv1 1414 Application Data, Application Data
TLSv1 290 Application Data
TLSv1 1724 Application Data, Application Data
TLSv1 1414 Application Data, Application Data
TLSv1 450 Application Data
TLSv1 1820 Application Data, Application Data
TLSv1 1060 Application Data, Application Data, Application Data,
Application Data, Application Data, Application Data,
Application Data, Application Data, Application Data,
Application Data
I assume that Firefox resends the request without the SNI extension in
case it gets back an error from the server as mentioned in the MSDN
blog:
"Unfortunately, anecdotal data indicates that some TLS servers in the
wild are not RFC-compliant and immediately fail the connection when TLS
extensions are present."
Thomas.
[7]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx schrieb am 14.01.2014 17:43:45:
> Von: [8]fourhundredguru@xxxxxxxxx
> An: [9]ftpapi@xxxxxxxxxxxxxxxxxxxxxx,
> Datum: 14.01.2014 19:04
> Betreff: Re: Server Name Indication?
> Gesendet von: [10]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>
> I have learned a good bit about Server Name Indication (SNI), but not
as
> much as I need to know.
>
>
> To make HTTPAPI work with SNI, I patched procedure https_init in
module
> COMMSSLR4. I hard-coded a call to gsk_attribute_set_buffer.
>
>
> eval rc = gsk_attribute_set_buffer(
>
> wkEnvh: 231:
>
> ServerName: 19)
>
> if rc <> GSK_OK
>
> callp SetError(HTTP_GSKKEYF:
>
> 'SNI error: ' +
>
> ssl_error(rc))
>
> callp https_cleanup
>
> return -1
>
> endif
>
>
>
> I used the value 231 in the second parm. Constant
> GSK_SSL_EXTN_SERVERNAME_CRITICAL_REQUEST would need to be defined in
> GSKSSL_H.
>
>
> It is possible that 230 would also work. If so, then constant
> GSK_SSL_EXTN_SERVERNAME_REQUEST would also need to be added to
GSKSSL_H.
>
>
> There was an error in one of IBM's programs that prevented me from
> connecting successfully to the web service. IBM fixed the program
with PTF
> MF57749. TR7 is prerequisite.
>
>
> As I understand it, SNI is relatively new and growing. People like
the
> idea of getting by with fewer IP addresses. If so, the need to
support SNI
> isn't going to go away. I don't know what the permanent solution is.
> Maybe https_init needs an optional fifth parameter for the host name.
If
> this parm is not blank, then https_init calls
gsk_attribute_set_buffer.
> But then I wonder if it should use 230 or 231.
>
>
> I am told that modern browsers support SNI, but I can't find any
> information on how they do so. Do they automatically send the
attribute
> for SNI? Do they try to connect without SNI, and if that doesn't
work,
> retry with the SNI attribute? I'd love to know. It seems to me that
> whatever they do, HTTPAPI needs to do the same.
>
>
> On Fri, Dec 13, 2013 at 5:52 PM, Mike Krebs
[11]<mkrebs@xxxxxxxxxxxxxxxxxx>wrote:
>
> > At least in 7.1, it appears to be in GSKIT
> >
> >
> >
[6][12]http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%
> 2Fapis%2Fgsk_attribute_set_buffer.htm
> >
> > GSK_SSL_EXTN_SERVERNAME_REQUEST (230)
> > GSK_SSL_EXTN_SERVERNAME_CRITICAL_REQUEST (231)
> > GSK_SSL_EXTN_SERVERNAME_LIST (232)
> > GSK_SSL_EXTN_SERVERNAME_CRITICAL_LIST (233)
> >
> >
> >
> >
> > -----Original Message-----
> > From: [13]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:
> > [14]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
> > Sent: Friday, December 13, 2013 3:18 PM
> > To: HTTPAPI and FTPAPI Projects
> > Subject: Re: Server Name Indication?
> >
> > Hi Ted,
> >
> > HTTPAPI does not have it's own code for SSL. It merely calls the
GSKit
> > APIs for SSL that IBM provides with the operating system.
> >
> > Server Name Indication (SNI) is a feature of SSL, not a feature of
HTTP,
> > so there's no way I can implement this. IBM would have to do it.
> >
> > -SK
> >
> >
> >
> > On 12/13/2013 9:23 AM, [15]ted_holt@xxxxxxxxxxxxxxxx wrote:
> > > Does HTTPAPI support Server Name Indication? I am having
trouble
> > > communicating with a Web service, and this is what they have
found
> > out
> > > from our trouble-shooting.
> > > The issue is something called ?SNI? or ?Server Name
Indication?. We
> > > have several API websites running off the same IP, each with
its own
> > > certificate. SNI forces the client to tell them what host
they are
> > > looking for so it knows which certificate to dish up. SNI is
built in
> > > to all modern day browsers and that?s why we don?t have any
problems
> > > from RestClient or any other testing facilities. If im
correct, I
> > don?t
> > > think the utility you are using is implementing SNI and when
it
> > > contacts our server the server doesn?t know what its looking
for.
> > >
> > > You were able to make a call to the api through SSL during
out test
> > > yesterday because I disabled SNI, and just set one
certificate for
> > the
> > > IP, but that renders all the other sites dead. SNI is a
fairly common
> > > thing, so the software you are using should have the ability
to
> > > implement it somewhere in there.
> > > Ted Holt
> > > Sr. Systems Analyst
> > > The Taylor Group of Companies
> > > 650 N. Church Avenue
> > > Louisville, MS 39339
> > > Phone: (662) 773-9186
> > > NOTICE:
> > > This message (with any attachments) is confidential and may
> > constitute
> > > a privileged communication. If you have received this message
in
> > error,
> > > please notify me immediately by telephone (662-773-3421) or
by
> > > electronic mail. Do not use or disclose this message in any
way.
> > > Thank you
> > >
> > >
> > >
> > >
-----------------------------------------------------------------------
> > > This is the FTPAPI mailing list. To unsubscribe, please go to:
> > > [7][16]http://www.scottklement.com/mailman/listinfo/ftpapi
> > >
-----------------------------------------------------------------------
> >
> >
-----------------------------------------------------------------------
> > This is the FTPAPI mailing list. To unsubscribe, please go to:
> > [8][17]http://www.scottklement.com/mailman/listinfo/ftpapi
> >
-----------------------------------------------------------------------
> >
>
>
>
> --
> ------------------------------------------------------
> Ted Holt
> Senior Technical Editor, Four Hundred Guru
> ==============================================
> Sign up for free IT-related newsletters at [9]www.itjungle.com!
> ==============================================
>
-----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> [10][18]http://www.scottklement.com/mailman/listinfo/ftpapi
>
-----------------------------------------------------------------------
--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a
criminal
offence. Please delete if obtained in error and email confirmation to
the sender.
References
1. [19]https://bugzilla.mozilla.org/show_bug.cgi?id=116168
2. [20]http://blogs.msdn.com/b/ie/archive/2005/10/22/483795.aspx
3. [21]http://www.ietf.org/rfc/rfc3546.txt
4. [22]http://http.xxx.xxx.xxx.xxx/xxx/
5. [23]http://http.xxx.xxx.xxx.xxx/xxx/
6. [24]http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%
7. [25]http://www.scottklement.com/mailman/listinfo/ftpapi
8. [26]http://www.scottklement.com/mailman/listinfo/ftpapi
9. [27]file://localhost/tmp/www.itjungle.com!
10. [28]http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
[29]http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
References
1. mailto:thomas.raddatz@xxxxxx
2. https://bugzilla.mozilla.org/show_bug.cgi?id=116168
3. http://blogs.msdn.com/b/ie/archive/2005/10/22/483795.aspx
4. http://www.ietf.org/rfc/rfc3546.txt
5. http://http.xxx.xxx.xxx.xxx/xxx/
6. http://http.xxx.xxx.xxx.xxx/xxx/
7. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
8. mailto:fourhundredguru@xxxxxxxxx
9. mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx
10. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
11. mailto:mkrebs@xxxxxxxxxxxxxxxxxx
12. http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%
13. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
14. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
15. mailto:ted_holt@xxxxxxxxxxxxxxxx
16. http://www.scottklement.com/mailman/listinfo/ftpapi
17. http://www.scottklement.com/mailman/listinfo/ftpapi
18. http://www.scottklement.com/mailman/listinfo/ftpapi
19. https://bugzilla.mozilla.org/show_bug.cgi?id=116168
20. http://blogs.msdn.com/b/ie/archive/2005/10/22/483795.aspx
21. http://www.ietf.org/rfc/rfc3546.txt
22. http://http.xxx.xxx.xxx.xxx/xxx/
23. http://http.xxx.xxx.xxx.xxx/xxx/
24. http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%
25. http://www.scottklement.com/mailman/listinfo/ftpapi
26. http://www.scottklement.com/mailman/listinfo/ftpapi
27. file://localhost/tmp/www.itjungle.com
28. http://www.scottklement.com/mailman/listinfo/ftpapi
29. http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------