设计一个EAP-TLS客户端问候消息 [英] Designing an EAP-TLS client hello message

问题描述

我想设计一个启动一个EAP-TLS握手的第一个包。这是我的包怎么看起来像目前：

的EAP部分我已经用C与相应的信息填写手动缓冲设计。该TLS部分衍生我使用OpenSSL如图所示<一个href=\"http://stackoverflow.com/questions/22753221/openssl-read-write-handshake-data-with-memory-bio\">in这个问题。然后我去了 RFC 并在添加了4个字节长度字段和TLS标志该分组。但Wireshark的拒绝接受它！我试图通过字节TLS数据字节比较TLS连接发生了TCP，我可以看到，对于客户端问候（十六进制16），TLS版本（0x0301：TLS 1.0）的字段是相同的顺序。你能帮我找出我要去哪里错了？谢谢！此外，如果任何人都知道一个客户端，可以生成这些消息，这样我可以比较他们，这将是有益的了。谢谢！

解决方案

您802.1X头说，包是227个字节。你有199个字节，并强调28字节不突出，使资金高达227好。

所以，如果你的整个数据包是227个字节，你EAP头肯定要少一些。除了你的EAP头说，EAP数据为227个字节，太多。

您EAP头应该是这样的：

  + ------ + ------ + ------------ + ------ + --- - 
| code | ID |长度|类型|数据...
+ ------ + ------ + ------------ + ------ + ----
 1字节1字节2字节1字节n字节
 

RFC2716 说：

  

长度

 长度字段为16字节，表示EAP的长度
  包包括code，标识符，长度，类型和数据
  领域。长度域的范围之外的八位位
  视为数据链路层填充，应该被忽略的
  接收。
 

所以，长度为起始 code 和去包，在这种情况下，我想会是年底的字节数 227 - 18 = 209

继续，我们看到，消息类型是13，所以这是一个EAP-TLS包。我看取值位未设置，这意味着该数据包是一个片段确认。那是对的吗？ （可能不是，但只有你会知道）

  

S位
        （EAP-TLS开始）是在EAP-TLS启动消息集。这个
        从片段区分EAP-TLS Start消息
        确认。

获取对EAP-TLS的长度，它告诉我们你的信息的总长度，如果你的有效载荷为s $ P $垫出过许多包。是数据包我们正在寻找你的整个TLS消息？只有你会知道你的消息是多久，什么它的长度。

  

TLS消息长度

 的TLS消息长度是4个字节，只有present
  如果L比特被置位。该字段提供的总长度
  TLS消息或在正在被碎片化的消息。
 

我假设整个消息是你突出的东西，所以它的长度为199。

即使一些细节上面都错了你的包，一般的想法是，你已经得到了长度错误，也许是标志是错误的了。

资源：

的http://www.netcraftsmen.net/resources/archived-articles/429-examining-8021x-and-eap.html

http://www.ietf.org/rfc/rfc2716.txt

I am trying to design the first packet that initiates an EAP-TLS handshake. This is how my packet looks like currently:

The EAP part I have designed by manually filling a buffer in C with the respective information. The TLS part I derived using OpenSSL as shown in this question. Then I went to the RFC and added the 4 octet length field and TLS flags in the packet. But wireshark refuses to accept it! I tried comparing the TLS data byte by byte to a TLS connection happening over TCP, and I can see that the fields for client hello (16 in hex), TLS version (0x0301: TLS 1.0) are in the same order. Can you help me identify where am I going wrong? Thank you! Also, if anyone knows a client that can generate these messages so I can compare them, it would be beneficial too. Thanks!

解决方案

Your 802.1X header says the packet is 227 bytes. You have 199 bytes highlighted and 28 bytes not highlighted, so that sums up to 227. Good.

So if your entire packet is 227 bytes, your EAP header certainly must be less than that. Except your EAP header says that the EAP data is 227 bytes, too.

Your EAP header should look like:

+------+------+------------+------+----
| code |  ID  |   length   | type | data ...
+------+------+------------+------+----
 1 byte 1 byte    2 bytes   1 byte  n bytes

RFC2716 says:

Length

  The Length field is two octets and indicates the length of the EAP
  packet including the Code, Identifier, Length, Type, and Data
  fields.  Octets outside the range of the Length field should be
  treated as Data Link Layer padding and should be ignored on
  reception.

So the length is the number of bytes starting at code and going to the end of the packet, which in this case I suppose would be 227 - 18 = 209.

Moving on, we see that the message type is 13, so it's an EAP-TLS packet. I see the S bit isn't set, which implies that this packet is a fragment acknowledgement. Is that correct? (probably not, but only you would know)

The S bit (EAP-TLS start) is set in an EAP-TLS Start message. This differentiates the EAP-TLS Start message from a fragment acknowledgement.

Getting to the EAP-TLS length, that tells us the total length of your message, in case your payload is spread out over many packets. Is the packet we're looking at your entire TLS message? Only you would know how long your message is and what its length is.

TLS Message Length

  The TLS Message Length field is four octets, and is present only
  if the L bit is set.  This field provides the total length of the
  TLS message or set of messages that is being fragmented.

I'm assuming the entire message is what you have highlighted, so its length would be 199.

Even if some of the details above are wrong for your packet, the general idea is that you've got the lengths wrong, and perhaps the flags are wrong, too.

Resources:

http://www.netcraftsmen.net/resources/archived-articles/429-examining-8021x-and-eap.html

http://www.ietf.org/rfc/rfc2716.txt

这篇关于设计一个EAP-TLS客户端问候消息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！