svenstaro/miniserve

Panic when using TLS

Closed this issue · 1 comments

hahanein commented

TLS doesn't work for me.

$ hostnamectl 
Operating System: Arch Linux                      
          Kernel: Linux 5.15.8-arch1-1
    Architecture: x86-64
$ rustc --version
rustc 1.59.0-nightly (5531927e8 2021-12-16)
$ miniserve --version
miniserve 0.18.0

I cargo install'd miniserve and provided the --locked flag, too.

$ RUST_BACKTRACE=full miniserve --tls-cert cert.pem --tls-key cert-key.pem
thread 'main' panicked at 'removal index (is 0) should be < len (is 0)', /home/benjamin/.cargo/registry/src/github.com-1ecc6299db9ec823/miniserve-0.18.0/src/config.rs:170:60
stack backtrace:
   0:     0x55b51e6040bd - std::backtrace_rs::backtrace::libunwind::trace::h8a4fbc0ad5037ed8
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x55b51e6040bd - std::backtrace_rs::backtrace::trace_unsynchronized::h1151c6be82648430
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55b51e6040bd - std::sys_common::backtrace::_print_fmt::h0e66188b887884d8
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x55b51e6040bd - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h73d0a18edef87a31
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x55b51e5464bc - core::fmt::write::hbd97d89fb6eddcb7
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/core/src/fmt/mod.rs:1149:17
   5:     0x55b51e602f14 - std::io::Write::write_fmt::h90c4c283000daeaa
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/std/src/io/mod.rs:1660:15
   6:     0x55b51e60349e - std::sys_common::backtrace::_print::h1eca9472cd205cd9
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x55b51e60349e - std::sys_common::backtrace::print::h8f3dc969a276be42
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x55b51e60349e - std::panicking::default_hook::{{closure}}::h88b9edeb4be8c2c7
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/std/src/panicking.rs:211:50
   9:     0x55b51e602cbf - std::panicking::default_hook::ha8ba539e60db6988
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/std/src/panicking.rs:228:9
  10:     0x55b51e602cbf - std::panicking::rust_panic_with_hook::h375a16940a54c331
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/std/src/panicking.rs:606:17
  11:     0x55b51e627f73 - std::panicking::begin_panic_handler::{{closure}}::h8d2b1e1321b644ac
  12:     0x55b51e627ef6 - std::sys_common::backtrace::__rust_end_short_backtrace::ha453b5fed599cb50
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/std/src/sys_common/backtrace.rs:139:18
  13:     0x55b51e627eb2 - rust_begin_unwind
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/std/src/panicking.rs:498:5
  14:     0x55b51e466480 - core::panicking::panic_fmt::h2fc0885d5656d845
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/core/src/panicking.rs:107:14
  15:     0x55b51e4656e1 - alloc::vec::Vec<T,A>::remove::assert_failed::h403524cafca87783
                               at /rustc/5531927e8af9b99ad923af4c827c91038bca51ee/library/alloc/src/vec/mod.rs:1397:13
  16:     0x55b51e4c4d87 - miniserve::main::h1cdd2bd1f1840241
  17:     0x55b51e49d520 - std::sys_common::backtrace::__rust_begin_short_backtrace::h72a234f208bf0690
  18:     0x55b51e49e48e - std::rt::lang_start::{{closure}}::h63582deb8a20e0d5
  19:     0x55b51e4cef47 - main
  20:     0x7fa6c6b24b25 - __libc_start_main
  21:     0x55b51e46aace - _start
  22:                0x0 - <unknown>
Aborted (core dumped)

Provided certificates look like this:

-----BEGIN CERTIFICATE-----
MIIDyzCCArOgAwIBAgIUVp7qGBBQDeeKUEsG7ltUi7w/IbIwDQYJKoZIhvcNAQEL
                             --- snip ---
VkiTymPc9ImA6U/9+1hyq1fgsiZYLvuD7Ftrzmjkl1FmrSmoRFE9qOEIrM84tx5O
/bCAQEFoOsWdW6tad7cF
-----END CERTIFICATE-----

Edit: I created these certificates using cfssl which apparently does not support PKCS#8.

Edit2: Can confirm. After converting my key to PKCS#8 all is fine.

Could we maybe get support for PKCS#1? :)

Edit3: Apparently, you're running right into this issue: rustls/rustls#173

Which is not going to be fixed because...

[...] https://crates.io/crates/rustls-pemfile now has preferable APIs (read_all) and contains the offending code.

Unfortunately, the API exposed by rustls-pemfile is incompatible with your rustls version's ServerConfig API.

Jikstra commented

I updated both rustls and rustls-pemfile in this pr: #677
There I for now handled to explicitly only load X509Certificate as the needed Certificate struct (https://docs.rs/rustls/latest/rustls/struct.Certificate.html) says the binary vector needs to be "The certificate must be DER-encoded X.509.". I don't know if the read_one api call somehow converts this, I don't know too much about rustls or tls at all. But reading your issue somehow remembered me of those lines of code. Probably I could just give back the Vec for RSAKey and PKCS8Key and things just work^tm?

  • 👍1