- mbed-tls - lists.trustedfirmware.org

"packets lost" in DTLS in "Record" layer

by saghili

Hello, I have a question about DTLS. Because of the latency, I need to disable the "packets lost" feature. Does MbedTLS provide the flag that we can disable resending the packet in case of the packet lost? For instance, if I have 3 packets 42, 43, and 44, is it possible to decrypt packet 44 without receiving packets 42 and 43? It will be in the "Record" layer. Thank you. Best regards, Farhad

4 years, 4 months

1
0
0 0

Re: [mbed-tls] mbedtls undefined behaviour

by Сысоев Андрей

Thank you for quick response. > Are you using blocking or non-blocking I/O? Non-blocking IO I've preset bio_send/recv callbacks I have pair of buffers, transport buffer and application buffer, for reading and writing (4 buffers total). Application buffers are protected by mutexes. Transport buffers are written/read in bio_send/recv (if no async op pending, otherwise WANT_READ/WRITE). mbedtls_ssl_xxx work with application buffers. > Are you using TLS or DTLS? What protocol version, what cipher suite and what extensions are negotiated? TLS (over tcp, no lossy channel involved) version 1.2 > Does your application call mbedtls_ssl_write() and mbedtls_ssl_read() again with the same buffer if they return MBEDTLS_ERR_SSL_WANT_READ or MBEDTLS_ERR_SSL_WANT_WRITE? Well, actually, no. AND it's quite possible, that application outgoing buffer (std::vector) has been relocated between mbedtls_ssl_write calls, because app could push data several times while async op was pending and bio_send returned WANT_WRITE, causing these buffers to resize. So buf.data() will not be equal to that from previous mbedtls_ssl_write call. Is this what causes trouble? It's somehow connected to partial sends? I do call ssl_write inside while-loop, counting sent and unsent bytes - thought this was enough. But if mbedtls somehow remembers addresses from previos calls - that might cause problems. > Do you close the TLS connection if mbedtls_ssl_xxx() returns an error other than WANT_XXX (or XXX_IN_PROGRESS if you use these features)? Yes, but that never happens (from handshake to until problem appears) > What is the value of MBEDTLS_SSL_MAX_CONTENT_LEN (or MBEDTLS_SSL_OUT_CONTENT_LEN if it's defined)? Not defined in config, looks like both 16834 >What operating system are you using? Ubuntu 20, Kali 20 > Is this a client or a server? What TLS stack does the other side run? Both are written same way, both using same library. I'll try to prepare test-case code, that reproduces the problem, and logs, but that will require some time. 10.12.2020 1:07, Gilles Peskine via mbed-tls пишет: > Hi Андрей, > > The behavior you describe is a bug. But there isn't enough information > to tell whether the bug is in Mbed TLS, in asio-standalone, in some > other third-party code, or in your application. > > Some things to consider: > > * Are you using blocking or non-blocking I/O? > * Are you using TLS or DTLS? What protocol version, what cipher suite > and what extensions are negotiated? > * Does your application call mbedtls_ssl_write() and mbedtls_ssl_read() > again with the same buffer if they return MBEDTLS_ERR_SSL_WANT_READ or > MBEDTLS_ERR_SSL_WANT_WRITE? > * Do you close the TLS connection if mbedtls_ssl_xxx() returns an error > other than WANT_XXX (or XXX_IN_PROGRESS if you use these features)? > * What is the value of MBEDTLS_SSL_MAX_CONTENT_LEN (or > MBEDTLS_SSL_OUT_CONTENT_LEN if it's defined)? > * What operating system are you using? > * Is this a client or a server? What TLS stack does the other side run? > > You'll give others the most chance to help you if you post small, > complete code to reproduce the problem. I realize this may be difficult. > A good intermediate way to see what is going on would be to post debug > logs. To get debug logs, make sure that MBEDTLS_DEBUG_C is enabled and > call these functions before opening the TLS connection: > > mbedtls_ssl_conf_dbg(&ssl_conf, my_debug, stdout); > mbedtls_debug_set_threshold(2); > > See https://tls.mbed.org/kb/how-to/mbedtls-tutorial for a sample version > of my_debug(). > > Calls to bio_send() are shown in the logs as > > => flush output > message length: %d, out_left: %d > ssl->f_send() returned %d > <= flush output > > If they don't show expected numbers, the rest of the logs should give a > clue as to why. > > Hope this helps, >

4 years, 4 months

1
0
0 0

Re: [mbed-tls] mbedtls undefined behaviour

by Gilles Peskine

By the way, I notice you're using Mbed TLS 2.16.3. This version has known bugs, including security issues. Please upgrade to the latest Mbed TLS 2.16.x (currently 2.16.8, very soon 2.16.9) which is a security and bugfix update, or to the latest release (2.24.0, soon 2.25.0) which has all the latest bugfixes and features. Looking at the changelog, I don't see any mention of a bug that could explain your problem, but I might have missed something. -- Gilles Peskine Mbed TLS developer On 09/12/2020 22:17, Сысоев Андрей via mbed-tls wrote: > Hello. > > I need a little help with mbedtls 2.16.3. > I'm using it under x86-64 with asio-standalone. > > Here's a standard situation: > - I call mbedtls_ssl_write() to write let's say 8192 bytes of payload > - it calls my own bio_send() with (8192+21) bytes as len parameter > - bio_send() returns len=(8192+21), indicating transport data > correctly written > - mbedtls_ssl_write() returns 8192, indicating payload send > GOOD: next I use this value to shift application buffer (erase first > 8192 bytes), then send next chunk > > BUT after some time of running this situation happens: > - once again, a call to mbedtls_ssl_write() to write let's say 8192 > bytes of payload > - it calls bio_send() with smaller number, about 5500 bytes as len > parameter (?? but OK) > - bio_send() returns len=5500, indicating transport data correctly > written > - mbedtls_ssl_write() returns 8192 (??? why not 5500 ???), indicating > payload send > BAD: next I use this value to shift application buffer (erase first > 8192 bytes), this leads to data loss of (8192-5500)=2692 bytes and > ruins protocol > > As you can see, mbedtls_ssl_write() incorrectly reports about sent > application data (8192 instead of 5500) - is this a bug? How can such > situation happen under normal operation? > > Thanks in advance. >

4 years, 4 months

1
0
0 0

Re: [mbed-tls] mbedtls undefined behaviour

by Gilles Peskine

Hi Андрей, The behavior you describe is a bug. But there isn't enough information to tell whether the bug is in Mbed TLS, in asio-standalone, in some other third-party code, or in your application. Some things to consider: * Are you using blocking or non-blocking I/O? * Are you using TLS or DTLS? What protocol version, what cipher suite and what extensions are negotiated? * Does your application call mbedtls_ssl_write() and mbedtls_ssl_read() again with the same buffer if they return MBEDTLS_ERR_SSL_WANT_READ or MBEDTLS_ERR_SSL_WANT_WRITE? * Do you close the TLS connection if mbedtls_ssl_xxx() returns an error other than WANT_XXX (or XXX_IN_PROGRESS if you use these features)? * What is the value of MBEDTLS_SSL_MAX_CONTENT_LEN (or MBEDTLS_SSL_OUT_CONTENT_LEN if it's defined)? * What operating system are you using? * Is this a client or a server? What TLS stack does the other side run? You'll give others the most chance to help you if you post small, complete code to reproduce the problem. I realize this may be difficult. A good intermediate way to see what is going on would be to post debug logs. To get debug logs, make sure that MBEDTLS_DEBUG_C is enabled and call these functions before opening the TLS connection: mbedtls_ssl_conf_dbg(&ssl_conf, my_debug, stdout); mbedtls_debug_set_threshold(2); See https://tls.mbed.org/kb/how-to/mbedtls-tutorial for a sample version of my_debug(). Calls to bio_send() are shown in the logs as => flush output message length: %d, out_left: %d ssl->f_send() returned %d <= flush output If they don't show expected numbers, the rest of the logs should give a clue as to why. Hope this helps, -- Gilles Peskine Mbed TLS developer On 09/12/2020 22:17, Сысоев Андрей via mbed-tls wrote: > Hello. > > I need a little help with mbedtls 2.16.3. > I'm using it under x86-64 with asio-standalone. > > Here's a standard situation: > - I call mbedtls_ssl_write() to write let's say 8192 bytes of payload > - it calls my own bio_send() with (8192+21) bytes as len parameter > - bio_send() returns len=(8192+21), indicating transport data > correctly written > - mbedtls_ssl_write() returns 8192, indicating payload send > GOOD: next I use this value to shift application buffer (erase first > 8192 bytes), then send next chunk > > BUT after some time of running this situation happens: > - once again, a call to mbedtls_ssl_write() to write let's say 8192 > bytes of payload > - it calls bio_send() with smaller number, about 5500 bytes as len > parameter (?? but OK) > - bio_send() returns len=5500, indicating transport data correctly > written > - mbedtls_ssl_write() returns 8192 (??? why not 5500 ???), indicating > payload send > BAD: next I use this value to shift application buffer (erase first > 8192 bytes), this leads to data loss of (8192-5500)=2692 bytes and > ruins protocol > > As you can see, mbedtls_ssl_write() incorrectly reports about sent > application data (8192 instead of 5500) - is this a bug? How can such > situation happen under normal operation? > > Thanks in advance. >

4 years, 4 months

1
0
0 0

mbedtls undefined behaviour

by Сысоев Андрей

Hello. I need a little help with mbedtls 2.16.3. I'm using it under x86-64 with asio-standalone. Here's a standard situation: - I call mbedtls_ssl_write() to write let's say 8192 bytes of payload - it calls my own bio_send() with (8192+21) bytes as len parameter - bio_send() returns len=(8192+21), indicating transport data correctly written - mbedtls_ssl_write() returns 8192, indicating payload send GOOD: next I use this value to shift application buffer (erase first 8192 bytes), then send next chunk BUT after some time of running this situation happens: - once again, a call to mbedtls_ssl_write() to write let's say 8192 bytes of payload - it calls bio_send() with smaller number, about 5500 bytes as len parameter (?? but OK) - bio_send() returns len=5500, indicating transport data correctly written - mbedtls_ssl_write() returns 8192 (??? why not 5500 ???), indicating payload send BAD: next I use this value to shift application buffer (erase first 8192 bytes), this leads to data loss of (8192-5500)=2692 bytes and ruins protocol As you can see, mbedtls_ssl_write() incorrectly reports about sent application data (8192 instead of 5500) - is this a bug? How can such situation happen under normal operation? Thanks in advance.

4 years, 4 months

1
0
0 0

Re: [mbed-tls] Implementing MbedTLS on "xilinx zu7 zynq ultrascale+soc"

by Gilles Peskine

Hi Farhad, Mbed TLS currently supports hardware acceleration through alternative implementations of the corresponding modules or functions. See https://tls.mbed.org/kb/development/hw_acc_guidelines . This mechanism is available for symmetric cryptography and partially for RSA and ECC. There is some work in progress on a new mechanism for hardware acceleration through the psa_xxx() API, which will be available for all algorithms. You can follow the work in progress on the “Unified driver interface: API design and prototype” epic at https://github.com/ARMmbed/mbedtls/projects/2#column-8543266 . Hope this helps, -- Gilles Peskine Mbed TLS developer On 04/12/2020 11:20, saghili via mbed-tls wrote: > Dear Sir/Madam, > > Our platform is a quad core Cortex A53 running PetaLinux. > In our hardware, "AF_ALG" module has performance accelerations > available through the Linux crypto drivers. > Is it possible that we have "AF_ALG" for offloading crypto operations? > > Best regards, > Farhad

4 years, 4 months

1
0
0 0

Implementing MbedTLS on "xilinx zu7 zynq ultrascale+soc"

by saghili

Dear Sir/Madam, Our platform is a quad core Cortex A53 running PetaLinux. In our hardware, "AF_ALG" module has performance accelerations available through the Linux crypto drivers. Is it possible that we have "AF_ALG" for offloading crypto operations? Best regards, Farhad

4 years, 4 months

1
0
0 0

Mbed TLS on ESP32

by Radim Kohout

Hello, I am using ESP32 Dev Module, which supports MbedTLS. I have two questions, but I can't find the answer on the forum: 1.Is there any way to import RSA keys from string(ideally from PEM format) to mbedtls_pk context? 2.How to encrypt with RSA private key and decrypt with RSA public key? Thanks Radim Kohout

4 years, 4 months

1
0
0 0

Re: [mbed-tls] Invalid ECDSA signature created

by ROSHINI DEVI

Thanks Gilles. I have use mbedtls_ecdsa_sign and got the raw buffer output of R & S values. On Sun, Nov 22, 2020, 9:26 PM Gilles Peskine via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hi Roshini, > > Mathematically, an ES256 (ECDSA over the curve P256R1) signature is a > pair of numbers (r,s) between 1 and an upper bound which is very > slightly less than 2^256. There are two common representations for this > signature. JWA uses the “raw” representation: two big-endian numbers > represented each with exactly 32 bytes, concatenated together. > mbedtls_ecdsa_write_signature uses the ASN.1 DER representation, which > as you noticed represents each number in a type+length+value format. > > The DER format removes leading zeros from the number, then adds a > leading 0 bit to each number which is a sign bit (the numbers in an > ECDSA signature are always positive, but DER can also represent negative > numbers). Therefore each number has a roughly 1/2 chance of using 33 > value bytes with a leading 0 byte (1 sign bit + 7 value bits, all 0), a > 63/128 chance of using 32 value bytes, and a 1/128 chance of using 31 > value bytes or less because the 7 most significant bits of the number > were 0. A shorter number in an ECDSA signature is not invalid, it's a > 1/128 chance (independently for each of r and s). > > To get the signature in raw format with Mbed TLS, the easiest way is to > use the PSA API, where the output of psa_sign_hash() for ECDSA is the > raw format. With the classic Mbed TLS API, the easiest way is to call > mbedtls_ecdsa_sign() or mbedtls_ecdsa_sign_det_ext() to get r and s as > bignums, then use mbedtls_mpi_write_binary() to write r and s with their > exact size into the output buffer. You can find an example in the > internal function psa_ecdsa_sign(): > > https://github.com/ARMmbed/mbedtls/blob/mbedtls-2.24.0/library/psa_crypto.c… > > Hope this helps, > > -- > Gilles Peskine > Mbed TLS developer > > On 22/11/2020 10:12, ROSHINI DEVI via mbed-tls wrote: > > Hello all, > > > > I need to sign the message using ES256 algorithm. After doing > > necessary initializations, I called API > > - mbedtls_ecdsa_write_signature() API and it gave me signature in ASN1 > > encoded form and there was no error generated by this API. > > After getting the signature, I need the r & s values to create JWT > > Token. So, I wrote my custom function to parse the signature buffer > > and get the R & S values of it. > > It was working fine. Sometimes, I am getting an invalid signature as > > shown below signature DER buffer - > > > > 30 43 02 1f 31 92 8d 22 10 41 86 25 68 7f 42 81 26 0f 37 bc 7f 38 b7 > > d5 1a 6b 69 31 07 34 11 a6 04 e5 90 02 20 23 26 f8 b9 80 cf 2c 25 c8 > > 04 b4 ac 43 51 6a 04 a6 af 8f 94 36 f8 cf 35 c2 94 cc df de db 92 b2 > > > > The reason for invalid is - > > 1st byte represents ASN1 sequence, followed by length and 3rd byter > > indicates it is an integer. > > Ideally, 4th byte indicates length of r-value, it should have been 32 > > or 33 bytes ( in case of padding with 00 ). You can see in the above > > buffer it is 0x1F ( 31 bytes ). It is really weird how it is possible > > to get the signature length of 31 bytes. > > > > It is blocking me for generation of JWT token, where in RFC 7518 > > - https://tools.ietf.org/html/rfc7518#page-9 , it says R & S must be > > 32 bytes long. And, the generation is failing. > > > > It is of high priority for me. If anyone can provide your suggestions > > on this issue, it would be really great. Thanks in advance > > > > Thanks, > > Roshini > > > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >

4 years, 4 months

1
0
0 0

-0x7180 - SSL - Verification of the message MAC failed

by Михаил Азанов

The SSL server is the one from the examples https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_server… It is configured on port 8080. The server runs on the linux operating system Linux commands give the following: uname -a Linux termv7 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux On the client side, the sim800 module is used. Log files attached to the email. File contents TermV-terminals-server.key: subject=/C=RU/ST=Sample/L=Sample/O=Sample/OU=Sample/CN=localhost issuer=/C=RU/ST=Sample/L=Sample/O=Sample/OU=Sample/CN=Sample -----BEGIN CERTIFICATE----- MIIDTjCCAjYCFBhhDBE3BeiTMD0dzFYOGILO8yq0MA0GCSqGSIb3DQEBCwUAMGIx CzAJBgNVBAYTAlJVMQ8wDQYDVQQIDAZTYW1wbGUxDzANBgNVBAcMBlNhbXBsZTEP MA0GA1UECgwGU2FtcGxlMQ8wDQYDVQQLDAZTYW1wbGUxDzANBgNVBAMMBlNhbXBs ZTAeFw0yMDAxMTgxODA5MDlaFw0yNDAxMTcxODA5MDlaMGUxCzAJBgNVBAYTAlJV MQ8wDQYDVQQIDAZTYW1wbGUxDzANBgNVBAcMBlNhbXBsZTEPMA0GA1UECgwGU2Ft cGxlMQ8wDQYDVQQLDAZTYW1wbGUxEjAQBgNVBAMMCWxvY2FsaG9zdDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALQSjObDf16fv02qH+3FtI4eX2tPfj+u XsSF8KK6OpcNNfHv17LB9NRUGbZdeikvL5mjB1qd8Qt5YBzSYvvNmuQqn/ZZhEhg 9zqDd+j6dsl03OSW42qSP59M22plqhHZv1ZpkbpHSnEbbwbIVhgx1GuJvMHbQKxw et3UobG9M7q0/6Z2hlvbiuQgZWpc6+vnGGFUzVFjJhsUMgewU1UwTtfahOVegv9v ocuj+AOHzzH2+l72ybpKIFKZ6eXjr3sVp1lIPXm+gUNLqkReNV2QVk4H/j2ow3xu hdHjiPQ+6o6dgbCHeCvbf7Qs35S8YlQH/Mn2bik2NIMKucdq7S35AEsCAwEAATAN BgkqhkiG9w0BAQsFAAOCAQEAhANjStGtYfPJ2Ibkbn6ct4bWLPe6sFBvbwYow3Fd lBz0oxBukhJDOrPa4OqJDpnWenXkEcUrulI2JG5sIylOg3QlwlmgPoJU9fkpmr+u xNVlTxBSh1BVp0sccC+LxNRyDMl4C89R1TjPpPjoRU4cciY9N0oygPjTj0c26qBU iqwtyJTeeJYJUdplCMvXFOt8deqi/NBpBGnEfo8P/IeM/iCWLD5VtloHX/R0C+au q6803qd1/Gd0pIdsELQKrR6mBz6sWukg2f25GheLQVV7Wz/elZD8MwYwjYLoCtIP 65Ae3Eb6S2KlsVPzMj09u6kQ+KPfZtKu8tiUSc+11hurRw== -----END CERTIFICATE----- File contents TermV-terminals-server.crt: -----BEGIN PRIVATE KEY----- MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQC0Eozmw39en79N qh/txbSOHl9rT34/rl7EhfCiujqXDTXx79eywfTUVBm2XXopLy+ZowdanfELeWAc 0mL7zZrkKp/2WYRIYPc6g3fo+nbJdNzkluNqkj+fTNtqZaoR2b9WaZG6R0pxG28G yFYYMdRribzB20CscHrd1KGxvTO6tP+mdoZb24rkIGVqXOvr5xhhVM1RYyYbFDIH sFNVME7X2oTlXoL/b6HLo/gDh88x9vpe9sm6SiBSmenl4697FadZSD15voFDS6pE XjVdkFZOB/49qMN8boXR44j0PuqOnYGwh3gr23+0LN+UvGJUB/zJ9m4pNjSDCrnH au0t+QBLAgMBAAECggEBAKWbKdpQkSME53sVqqeR26uYY0jdos4OHzm9tMDzZE7m 52XJniXYGsHrVnpRHbginTQ+qtS7zKMwzSO0mTPas0iDqvl0+iNWighWQEETl4tO 3peb7Spltf1bQa9oMDCagU2HaW5Xgi7jfAhQ1l0J9sGvutjOO3xbNaQtmUdNKfXa VRaof94/YKcbTPIn588orxfumgeiYwQ8exhA7yg1WLl2iSy9jj+8WrxaKvy4vR45 nXrb2tXletRoZZY/FC/NZNMgXsGTmYHl6blTEZVz7Zu0XPHKJo42tHnKHW46/ccJ vkXQNjUsu0JN95+lWBA5Yne8xddhiLNKv3DZ3iwXRAECgYEA17YaIbtlgSLd5hJJ OuS9n9XNUCEx1YLhDRzhHggPNTZkVxSnxnWVGpbubtWN/OggRtJyk+mLFV+aHLCa R224ofSPWWE1HtoSdtLcL5oLgp6RDoM61h1p1glFS7BpbYzBegAcbMJa1IvAMspx 5lsYowBUJLNHAEcqUrXzQ88gu2ECgYEA1bRugqLGXqz1E0z6o/MuGXfmJaGQEmJg 833As5jzsyd6pyznsB0TKUAJkcf0RmZrr1EDVigA9aLcwq4qThjGEL2FpGkOvXPC bY0c2pLnsZJetNmXnky/w+W127V+LbDjjQaYl/7c9Fp4hoomoykt7d1YW7lRZ2Le wo8muiGF5ysCgYEAlYHahMysop926tJ7vPzzTMfT4JjRQGnQ79S3VqhBWiFT1GM1 kcDHUkGQCnOrUMHWNSABV/FDe9HiL8Zbd+xdTqsBe/J67eI5b+/fuoJrPeIHKebc rbB/PWD5jWc8+zfWlWdkTCE88RnXYZyc6wryfW9p4nH7YP7yH5eKftIdnqECgYBl aWY33/661uDF8/XM742k0F0K5oxz7PONGNPlZmPfVJDD3G9mB6YcISNpZrXo4pmf bJZkwD8UUeDpEbVJsj/rmcRdrO0twk01p41Vu/jvL0J6F/f3SvyFffC6/nmOPS7+ sW6gUnWQD466abzEGLqO8kcH3/1dTnHfagc6tMXSWQKBgQCZjWzyLtEUxvWI2PSe B6/osxlYDyCkXrJDIT1LuepM/54Kre9YMUy2UZBVC42DR6paEbkAAqHdTsLNlKhV s+6/JGnEDR1e/L7ks0dBY8jow04r0mKG1M91SMLr5OeBTk6SRMnR7GAKewjeLmJD ULgsqyHSTh/4r6tDQ7Gayci2vQ== -----END PRIVATE KEY----- Server sources: #include <stdio.h> /* * SSL server demonstration program * * Copyright The Mbed TLS Contributors * SPDX-License-Identifier: Apache-2.0 * * Licensed under the Apache License, Version 2.0 (the "License"); you may * not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ #if !defined(MBEDTLS_CONFIG_FILE) #include "mbedtls/config.h" #else #include MBEDTLS_CONFIG_FILE #endif #if defined(MBEDTLS_PLATFORM_C) #include "mbedtls/platform.h" #else #include <stdio.h> #include <stdlib.h> #define mbedtls_time time #define mbedtls_time_t time_t #define mbedtls_fprintf fprintf #define mbedtls_printf printf #define mbedtls_exit exit #define MBEDTLS_EXIT_SUCCESS EXIT_SUCCESS #define MBEDTLS_EXIT_FAILURE EXIT_FAILURE #endif #if !defined(MBEDTLS_BIGNUM_C) || !defined(MBEDTLS_CERTS_C) || \ !defined(MBEDTLS_ENTROPY_C) || !defined(MBEDTLS_SSL_TLS_C) || \ !defined(MBEDTLS_SSL_SRV_C) || !defined(MBEDTLS_NET_C) || \ !defined(MBEDTLS_RSA_C) || !defined(MBEDTLS_CTR_DRBG_C) || \ !defined(MBEDTLS_X509_CRT_PARSE_C) || !defined(MBEDTLS_FS_IO) || \ !defined(MBEDTLS_PEM_PARSE_C) int main( void ) { mbedtls_printf("MBEDTLS_BIGNUM_C and/or MBEDTLS_CERTS_C and/or MBEDTLS_ENTROPY_C " "and/or MBEDTLS_SSL_TLS_C and/or MBEDTLS_SSL_SRV_C and/or " "MBEDTLS_NET_C and/or MBEDTLS_RSA_C and/or " "MBEDTLS_CTR_DRBG_C and/or MBEDTLS_X509_CRT_PARSE_C " "and/or MBEDTLS_PEM_PARSE_C not defined.\n"); mbedtls_exit( 0 ); } #else #include <stdlib.h> #include <string.h> #if defined(_WIN32) #include <windows.h> #endif #include "mbedtls/entropy.h" #include "mbedtls/ctr_drbg.h" #include "mbedtls/certs.h" #include "mbedtls/x509.h" #include "mbedtls/ssl.h" #include "mbedtls/net_sockets.h" #include "mbedtls/error.h" #include "mbedtls/debug.h" #if defined(MBEDTLS_SSL_CACHE_C) #include "mbedtls/ssl_cache.h" #endif #define HTTP_RESPONSE \ "HTTP/1.0 200 OK\r\nContent-Type: text/html\r\n\r\n" \ "<h2>mbed TLS Test Server</h2>\r\n" \ "<p>Successful connection using: %s</p>\r\n" #define DEBUG_LEVEL 5 static void my_debug( void *ctx, int level, const char *file, int line, const char *str ) { ((void) level); mbedtls_fprintf( (FILE *) ctx, "%s:%04d: %s", file, line, str ); fflush( (FILE *) ctx ); } int main( void ) { int ret, len; mbedtls_net_context listen_fd, client_fd; unsigned char buf[1024]; const char *pers = "ssl_server"; mbedtls_entropy_context entropy; mbedtls_ctr_drbg_context ctr_drbg; mbedtls_ssl_context ssl; mbedtls_ssl_config conf; mbedtls_x509_crt srvcert; mbedtls_pk_context pkey; #if defined(MBEDTLS_SSL_CACHE_C) mbedtls_ssl_cache_context cache; #endif mbedtls_net_init( &listen_fd ); mbedtls_net_init( &client_fd ); mbedtls_ssl_init( &ssl ); mbedtls_ssl_config_init( &conf ); #if defined(MBEDTLS_SSL_CACHE_C) mbedtls_ssl_cache_init( &cache ); #endif mbedtls_x509_crt_init( &srvcert ); mbedtls_pk_init( &pkey ); mbedtls_entropy_init( &entropy ); mbedtls_ctr_drbg_init( &ctr_drbg ); #if defined(MBEDTLS_DEBUG_C) mbedtls_debug_set_threshold( DEBUG_LEVEL ); #endif /* * 1. Load the certificates and private RSA key */ mbedtls_printf( "\n . Loading the server cert. and key..." ); fflush( stdout ); /* * This demonstration program uses embedded test certificates. * Instead, you may want to use mbedtls_x509_crt_parse_file() to read the * server and CA certificates, as well as mbedtls_pk_parse_keyfile(). */ ret = mbedtls_x509_crt_parse_file( &srvcert,"/etc/minpay/cert/TermV-terminals-server.crt"); if( ret != 0 ) { mbedtls_printf( " failed\n ! mbedtls_x509_crt_parse returned %d\n\n", ret ); goto exit; } ret = mbedtls_pk_parse_keyfile( &pkey,"/etc/minpay/cert/TermV-terminals-server.key", NULL ); if( ret != 0 ) { mbedtls_printf( " failed\n ! mbedtls_x509_crt_parse returned %d\n\n", ret ); goto exit; } mbedtls_printf( " ok\n" ); /* * 2. Setup the listening TCP socket */ mbedtls_printf( " . Bind on https://localhost:8080/ ..." ); fflush( stdout ); if( ( ret = mbedtls_net_bind( &listen_fd, NULL, "8080", MBEDTLS_NET_PROTO_TCP ) ) != 0 ) { mbedtls_printf( " failed\n ! mbedtls_net_bind returned %d\n\n", ret ); goto exit; } mbedtls_printf( " ok\n" ); /* * 3. Seed the RNG */ mbedtls_printf( " . Seeding the random number generator..." ); fflush( stdout ); if( ( ret = mbedtls_ctr_drbg_seed( &ctr_drbg, mbedtls_entropy_func, &entropy, (const unsigned char *) pers, strlen( pers ) ) ) != 0 ) { mbedtls_printf( " failed\n ! mbedtls_ctr_drbg_seed returned %d\n", ret ); goto exit; } mbedtls_printf( " ok\n" ); /* * 4. Setup stuff */ mbedtls_printf( " . Setting up the SSL data...." ); fflush( stdout ); if( ( ret = mbedtls_ssl_config_defaults( &conf, MBEDTLS_SSL_IS_SERVER, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT ) ) != 0 ) { mbedtls_printf( " failed\n ! mbedtls_ssl_config_defaults returned %d\n\n", ret ); goto exit; } mbedtls_ssl_conf_rng( &conf, mbedtls_ctr_drbg_random, &ctr_drbg ); mbedtls_ssl_conf_dbg( &conf, my_debug, stdout ); #if defined(MBEDTLS_SSL_CACHE_C) mbedtls_ssl_conf_session_cache( &conf, &cache, mbedtls_ssl_cache_get, mbedtls_ssl_cache_set ); #endif mbedtls_ssl_conf_ca_chain( &conf, srvcert.next, NULL ); if( ( ret = mbedtls_ssl_conf_own_cert( &conf, &srvcert, &pkey ) ) != 0 ) { mbedtls_printf( " failed\n ! mbedtls_ssl_conf_own_cert returned %d\n\n", ret ); goto exit; } if( ( ret = mbedtls_ssl_setup( &ssl, &conf ) ) != 0 ) { mbedtls_printf( " failed\n ! mbedtls_ssl_setup returned %d\n\n", ret ); goto exit; } mbedtls_printf( " ok\n" ); reset: #ifdef MBEDTLS_ERROR_C if( ret != 0 ) { char error_buf[100]; mbedtls_strerror( ret, error_buf, 100 ); mbedtls_printf("Last error was: %d - %s\n\n", ret, error_buf ); } #endif mbedtls_net_free( &client_fd ); mbedtls_ssl_session_reset( &ssl ); /* * 3. Wait until a client connects */ mbedtls_printf( " . Waiting for a remote connection ..." ); fflush( stdout ); if( ( ret = mbedtls_net_accept( &listen_fd, &client_fd, NULL, 0, NULL ) ) != 0 ) { mbedtls_printf( " failed\n ! mbedtls_net_accept returned %d\n\n", ret ); goto exit; } mbedtls_ssl_set_bio( &ssl, &client_fd, mbedtls_net_send, mbedtls_net_recv, NULL ); mbedtls_printf( " ok\n" ); /* * 5. Handshake */ mbedtls_printf( " . Performing the SSL/TLS handshake..." ); fflush( stdout ); while( ( ret = mbedtls_ssl_handshake( &ssl ) ) != 0 ) { if( ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE ) { mbedtls_printf( " failed\n ! mbedtls_ssl_handshake returned %d\n\n", ret ); goto reset; } } mbedtls_printf( " ok\n" ); /* * 6. Read the HTTP Request */ mbedtls_printf( " < Read from client:" ); fflush( stdout ); do { len = sizeof( buf ) - 1; memset( buf, 0, sizeof( buf ) ); ret = mbedtls_ssl_read( &ssl, buf, len ); if( ret == MBEDTLS_ERR_SSL_WANT_READ || ret == MBEDTLS_ERR_SSL_WANT_WRITE ) continue; if( ret <= 0 ) { switch( ret ) { case MBEDTLS_ERR_SSL_PEER_CLOSE_NOTIFY: mbedtls_printf( " connection was closed gracefully\n" ); break; case MBEDTLS_ERR_NET_CONN_RESET: mbedtls_printf( " connection was reset by peer\n" ); break; default: mbedtls_printf( " mbedtls_ssl_read returned -0x%x\n", (unsigned int) -ret ); break; } break; } len = ret; mbedtls_printf( " %d bytes read\n\n%s", len, (char *) buf ); if( ret > 0 ) break; } while( 1 ); /* * 7. Write the 200 Response */ mbedtls_printf( " > Write to client:" ); fflush( stdout ); len = sprintf( (char *) buf, HTTP_RESPONSE, mbedtls_ssl_get_ciphersuite( &ssl ) ); while( ( ret = mbedtls_ssl_write( &ssl, buf, len ) ) <= 0 ) { if( ret == MBEDTLS_ERR_NET_CONN_RESET ) { mbedtls_printf( " failed\n ! peer closed the connection\n\n" ); goto reset; } if( ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE ) { mbedtls_printf( " failed\n ! mbedtls_ssl_write returned %d\n\n", ret ); goto exit; } } len = ret; mbedtls_printf( " %d bytes written\n\n%s\n", len, (char *) buf ); mbedtls_printf( " . Closing the connection..." ); while( ( ret = mbedtls_ssl_close_notify( &ssl ) ) < 0 ) { if( ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE ) { mbedtls_printf( " failed\n ! mbedtls_ssl_close_notify returned %d\n\n", ret ); goto reset; } } mbedtls_printf( " ok\n" ); ret = 0; goto reset; exit: #ifdef MBEDTLS_ERROR_C if( ret != 0 ) { char error_buf[100]; mbedtls_strerror( ret, error_buf, 100 ); mbedtls_printf("Last error was: %d - %s\n\n", ret, error_buf ); } #endif mbedtls_net_free( &client_fd ); mbedtls_net_free( &listen_fd ); mbedtls_x509_crt_free( &srvcert ); mbedtls_pk_free( &pkey ); mbedtls_ssl_free( &ssl ); mbedtls_ssl_config_free( &conf ); #if defined(MBEDTLS_SSL_CACHE_C) mbedtls_ssl_cache_free( &cache ); #endif mbedtls_ctr_drbg_free( &ctr_drbg ); mbedtls_entropy_free( &entropy ); #if defined(_WIN32) mbedtls_printf( " Press Enter to exit this program.\n" ); fflush( stdout ); getchar(); #endif mbedtls_exit( ret ); } #endif /* MBEDTLS_BIGNUM_C && MBEDTLS_CERTS_C && MBEDTLS_ENTROPY_C && MBEDTLS_SSL_TLS_C && MBEDTLS_SSL_SRV_C && MBEDTLS_NET_C && MBEDTLS_RSA_C && MBEDTLS_CTR_DRBG_C && MBEDTLS_X509_CRT_PARSE_C && MBEDTLS_FS_IO && MBEDTLS_PEM_PARSE_C */ Regards, Michael.

4 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls